[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8599:
-

In addition there is a bug in the test: It sets the "correct" server address in 
another thread but there is no synchronization. This may work many times but 
fails easily, especially on highly parallel CPU architectures! Making the 
zkServerAddress volatile would be a fix, but as its for testing only, it is not 
a good idea.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8599:
-

Hi,
why not make the setter of the zkAddress package private? Test is in same 
package, so it does not need to be fully public!

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Comment Edited] (SOLR-8522) ImplicitSnitch to support IPv4 fragment tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou edited comment on SOLR-8522 at 2/23/16 7:17 AM:
---

Patch updated to latest git master branch


was (Author: arcadius):
Patch updated to git master branch

> ImplicitSnitch to support IPv4 fragment tags
> 
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



--
This message was sent by Atlassian 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-8522) ImplicitSnitch to support IPv4 fragment tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8522:
-
Summary: ImplicitSnitch to support IPv4 fragment tags  (was: ImplicitSnitch 
to support IPv4 fragment fragment tags)

> ImplicitSnitch to support IPv4 fragment tags
> 
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



--
This message was sent by Atlassian 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-8522) ImplicitSnitch to support IPv4 fragment fragment tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8522:
-
Attachment: SOLR-8522.patch

Patch updated to git master branch

> ImplicitSnitch to support IPv4 fragment fragment tags
> -
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



--
This message was sent by Atlassian 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-7026) AnalyzingInfixSuggester doesn't support Phrase Queries for contexts

[Kamaldeep Singh (JIRA)]

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

Kamaldeep Singh resolved LUCENE-7026.
-
Resolution: Cannot Reproduce

> AnalyzingInfixSuggester doesn't support Phrase Queries for contexts
> ---
>
> Key: LUCENE-7026
> URL: https://issues.apache.org/jira/browse/LUCENE-7026
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 5.3.1
>Reporter: Kamaldeep Singh
>
> AnalyzingInfixSuggester uses Term Queries for filtering out the contexts. If 
> the StandardAnalyzer is used while indexing , since all the contexts are 
> stored as StringField and analyzed , spaces in them  are removed and words 
> converted to tokens. So contexts having spaces in their terms can't be 
> queried , And we also can't pass a PhraseQuery as a BooleanQuery to lookup() 
> since Phrase Queries won't work on string fields where positions of tokens 
> are not stored. 
> Option left is to use a different analyzer while indexing 
> Analyzing Infix Suggester should store contexts as TextField instead of 
> StringField so they can be queried. 



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

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

[JENKINS] Lucene-Solr-5.5-Windows (32bit/jdk1.7.0_80) - Build # 22 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/22/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseSerialGC

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

Error Message:
timed out waiting for collection1 startAt time to exceed: Tue Feb 23 00:23:43 
CST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Tue Feb 23 00:23:43 CST 2016
at 
__randomizedtesting.SeedInfo.seed([256005CF2A7A5BC1:FECB05092F523272]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1419)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:771)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 11482 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   

[JENKINS] Lucene-Solr-Tests-5.5-Java7 - Build # 27 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java7/27/

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

Error Message:
QUERY FAILED: 
xpath=/response/arr[@name='fields']/lst/str[@name='name'][.='newTestFieldInt447']
  request=/schema/fields?wt=xml  response=  0   508
  _root_ string 
true false 
true   _version_ long true true   
constantField tdouble   
id string  
   true true 
false true 
true   newTestFieldInt0 tlong  
 newTestFieldInt1 tlong   newTestFieldInt10 tlong  
 newTestFieldInt100 tlong   newTestFieldInt101 tlong 
  newTestFieldInt102 tlong   newTestFieldInt103 tlong 
  newTestFieldInt104 tlong   newTestFieldInt105 tlong 
  newTestFieldInt106 tlong   newTestFieldInt107 tlong 
  newTestFieldInt108 tlong   newTestFieldInt109 tlong 
  newTestFieldInt11 tlong   newTestFieldInt110 tlong 
  newTestFieldInt111 tlong   newTestFieldInt112 tlong 
  newTestFieldInt113 tlong   newTestFieldInt114 tlong 
  newTestFieldInt115 tlong   newTestFieldInt116 tlong 
  newTestFieldInt117 tlong   newTestFieldInt118 tlong 
  newTestFieldInt119 tlong   newTestFieldInt12 tlong  
 newTestFieldInt120 tlong   newTestFieldInt121 tlong 
  newTestFieldInt122 tlong   newTestFieldInt123 tlong 
  newTestFieldInt124 tlong   newTestFieldInt125 tlong 
  newTestFieldInt126 tlong   newTestFieldInt127 tlong 
  newTestFieldInt128 tlong   newTestFieldInt129 tlong 
  newTestFieldInt13 tlong   newTestFieldInt130 tlong 
  newTestFieldInt131 tlong   newTestFieldInt132 tlong 
  newTestFieldInt133 tlong   newTestFieldInt134 tlong 
  newTestFieldInt135 tlong   newTestFieldInt136 tlong 
  newTestFieldInt137 tlong   newTestFieldInt138 tlong 
  newTestFieldInt139 tlong   newTestFieldInt14 tlong  
 newTestFieldInt140 tlong   newTestFieldInt141 tlong 
  newTestFieldInt142 tlong   newTestFieldInt143 tlong 
  newTestFieldInt144 tlong   newTestFieldInt145 tlong 
  newTestFieldInt146 tlong   newTestFieldInt147 tlong 
  newTestFieldInt148 tlong   newTestFieldInt149 tlong 
  newTestFieldInt15 tlong   newTestFieldInt150 tlong 
  newTestFieldInt151 tlong   newTestFieldInt152 tlong 
  newTestFieldInt153 tlong   newTestFieldInt154 tlong 
  newTestFieldInt155 tlong   newTestFieldInt156 tlong 
  newTestFieldInt157 tlong   newTestFieldInt158 tlong 
  newTestFieldInt159 tlong   newTestFieldInt16 tlong  
 newTestFieldInt160 tlong   newTestFieldInt161 tlong 
  newTestFieldInt162 tlong   newTestFieldInt163 tlong 
  newTestFieldInt164 tlong   newTestFieldInt165 tlong 
  newTestFieldInt166 tlong   newTestFieldInt167 tlong 
  newTestFieldInt168 tlong   newTestFieldInt169 tlong 
  newTestFieldInt17 tlong   newTestFieldInt170 tlong 
  newTestFieldInt171 tlong   newTestFieldInt172 tlong 
  newTestFieldInt173 tlong   newTestFieldInt174 tlong 
  newTestFieldInt175 tlong   newTestFieldInt176 tlong 
  newTestFieldInt177 tlong   newTestFieldInt178 tlong 
  newTestFieldInt179 tlong   newTestFieldInt18 tlong  
 newTestFieldInt180 tlong   newTestFieldInt181 tlong 
  newTestFieldInt182 tlong   newTestFieldInt183 tlong 
  newTestFieldInt184 tlong   newTestFieldInt185 tlong 
  newTestFieldInt186 tlong   newTestFieldInt187 tlong 
  newTestFieldInt188 tlong   newTestFieldInt189 tlong 
  newTestFieldInt19 tlong   newTestFieldInt190 tlong 
  newTestFieldInt191 tlong   newTestFieldInt192 tlong 
  newTestFieldInt193 tlong   newTestFieldInt194 tlong 
  newTestFieldInt195 tlong   newTestFieldInt196 tlong 
  newTestFieldInt197 tlong   newTestFieldInt198 tlong 
  newTestFieldInt199 tlong   newTestFieldInt2 tlong  
 

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

[Chris Hostetter]

Mike: since the ref guide is now up 2 80% of the mirrors, and i still 
haven't seen ANNOUNCEMENT emails from you, i'm going to go ahead and 
update the 5.5 release annoucnement text to include the ref guide notes 
(and site news items) rather then send out a seperate announcement.



: Date: Mon, 22 Feb 2016 13:46:55 -0700 (MST)
: From: Chris Hostetter 
: To: Lucene Dev 
: Cc: gene...@lucene.apache.org
: Subject: Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf
: 
: 
: VOTE has passed, i'll begin pushing to mirrors.
: 
: 
: : Date: Fri, 19 Feb 2016 16:05:18 -0700 (MST)
: : From: Chris Hostetter 
: : To: Lucene Dev 
: : Cc: gene...@lucene.apache.org
: : Subject: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf
: : 
: : 
: : Please VOTE to release the following artifacts as
: : apache-solr-ref-guide-5.5.pdf ...
: : 
: : 
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC1/
: : 
: : -Hoss
: : http://www.lucidworks.com/
: : 
: 
: -Hoss
: http://www.lucidworks.com/
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-7362) TestReqParamsAPI failing in jenkins

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7362:
--

non reproducible after so many runs , re-enabling the tests

> TestReqParamsAPI failing in jenkins
> ---
>
> Key: SOLR-7362
> URL: https://issues.apache.org/jira/browse/SOLR-7362
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> {noformat}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4645/
> Java: 32bit/jdk1.8.0_40 -server -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":1},   "response":{ 
> "znodeVersion":3, "params":{   "x":{ "a":"A val", 
> "b":"B val", "":{"v":0}},   "y":{ "p":"P val", 
> "q":"Q val", "":{"v":0}
> Stack Trace:
> java.lang.AssertionError: Could not get expected value  'null' for path 
> 'response/params/y/p' full output: {
>   "responseHeader":{
> "status":0,
> "QTime":1},
>   "response":{
> "znodeVersion":3,
> "params":{
>   "x":{
> "a":"A val",
> "b":"B val",
> "":{"v":0}},
>   "y":{
> "p":"P val",
> "q":"Q val",
> "":{"v":0}
> at 
> __randomizedtesting.SeedInfo.seed([D0DB18ECE165C505:588F27364F99A8FD]: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:405)
> at 
> org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
> at 
> org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:71)
> {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-7362) TestReqParamsAPI failing in jenkins

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7362


> TestReqParamsAPI failing in jenkins
> ---
>
> Key: SOLR-7362
> URL: https://issues.apache.org/jira/browse/SOLR-7362
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> {noformat}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4645/
> Java: 32bit/jdk1.8.0_40 -server -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":1},   "response":{ 
> "znodeVersion":3, "params":{   "x":{ "a":"A val", 
> "b":"B val", "":{"v":0}},   "y":{ "p":"P val", 
> "q":"Q val", "":{"v":0}
> Stack Trace:
> java.lang.AssertionError: Could not get expected value  'null' for path 
> 'response/params/y/p' full output: {
>   "responseHeader":{
> "status":0,
> "QTime":1},
>   "response":{
> "znodeVersion":3,
> "params":{
>   "x":{
> "a":"A val",
> "b":"B val",
> "":{"v":0}},
>   "y":{
> "p":"P val",
> "q":"Q val",
> "":{"v":0}
> at 
> __randomizedtesting.SeedInfo.seed([D0DB18ECE165C505:588F27364F99A8FD]: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:405)
> at 
> org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
> at 
> org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:71)
> {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] [Updated] (LUCENE-7043) add BigIntegerPoint and InetAddressPoint to sandbox

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7043:

Attachment: LUCENE-7043.patch

some minor cleanups, and adding prefix/CIDR range query for the 
InetAddressPoint (this is just sugar for an ordinary range).

> add BigIntegerPoint and InetAddressPoint to sandbox
> ---
>
> Key: LUCENE-7043
> URL: https://issues.apache.org/jira/browse/LUCENE-7043
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7043.patch, LUCENE-7043.patch
>
>
> We can now index 128-bit quantities, but still, making Fields for these is a 
> bit of work: you have to do some numericutils sign-extension/sign-flipping 
> magic for BigInteger quantities, deal with ipv4-mapped ipv6 addresses, etc.
> We can just provide some simple field types that also have static factory 
> methods for exact match/ranges.
> The BigIntegerPoint is N-dimensional, so acts just like any other primitive, 
> except its bigger (e.g. long long).
> InetAddressPoint is 1-dimensional by nature: of course you can have multiple 
> values per field, thats different. Since we prefix-compress values, we can 
> just map IPv4 addresses to IPv6 space and it works for both types. This is 
> consistent with what InetAddress does itself anyway.



--
This message was sent by Atlassian 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-7021) Leader will not publish core as active without recovering first, but never recovers

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7021:
---

This is probably due to a bunch of Leader Initiated Recovery bugs that have 
since been fixed.

> Leader will not publish core as active without recovering first, but never 
> recovers
> ---
>
> Key: SOLR-7021
> URL: https://issues.apache.org/jira/browse/SOLR-7021
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10
>Reporter: James Hardwick
>Priority: Critical
>  Labels: recovery, solrcloud, zookeeper
>
> A little background: 1 core solr-cloud cluster across 3 nodes, each with its 
> own shard and each shard with a single replica hence each replica is itself a 
> leader. 
> For reasons we won't get into, we witnessed a shard go down in our cluster. 
> We restarted the cluster but our core/shards still did not come back up. 
> After inspecting the logs, we found this:
> {code}
> 015-01-21 15:51:56,494 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - We are http://xxx.xxx.xxx.35:8081/solr/xyzcore/ and leader is 
> http://xxx.xxx.xxx.35:8081/solr/xyzcore/
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - No LogReplay needed for core=xyzcore baseURL=http://xxx.xxx.xxx.35:8081/solr
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - I am the leader, no recovery necessary
> 2015-01-21 15:51:56,496 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=active collection=xyzcore
> 2015-01-21 15:51:56,497 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - publishing core=xyzcore state=down collection=xyzcore
> 2015-01-21 15:51:56,498 [coreZkRegister-1-thread-2] INFO  cloud.ZkController  
> - numShards not found on descriptor - reading it from system property
> 2015-01-21 15:51:56,501 [coreZkRegister-1-thread-2] ERROR core.ZkContainer  - 
> :org.apache.solr.common.SolrException: Cannot publish state of core 'xyzcore' 
> as active without recovering first!
>   at org.apache.solr.cloud.ZkController.publish(ZkController.java:1075)
> {code}
> And at this point the necessary shards never recover correctly and hence our 
> core never returns to a functional state. 



--
This message was sent by Atlassian 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-7043) add BigIntegerPoint and InetAddressPoint to sandbox

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7043:

Attachment: LUCENE-7043.patch

patch adding both of these to sandbox.

there are some core changes but they are really unrelated:
* toString's for Int/Long/Float/DoublePoint were useless.
* Int/Long/Float/DoublePoint were not tested by TestField.
* NumericUtils big integer methods needed some cleanups.

> add BigIntegerPoint and InetAddressPoint to sandbox
> ---
>
> Key: LUCENE-7043
> URL: https://issues.apache.org/jira/browse/LUCENE-7043
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7043.patch
>
>
> We can now index 128-bit quantities, but still, making Fields for these is a 
> bit of work: you have to do some numericutils sign-extension/sign-flipping 
> magic for BigInteger quantities, deal with ipv4-mapped ipv6 addresses, etc.
> We can just provide some simple field types that also have static factory 
> methods for exact match/ranges.
> The BigIntegerPoint is N-dimensional, so acts just like any other primitive, 
> except its bigger (e.g. long long).
> InetAddressPoint is 1-dimensional by nature: of course you can have multiple 
> values per field, thats different. Since we prefix-compress values, we can 
> just map IPv4 addresses to IPv6 space and it works for both types. This is 
> consistent with what InetAddress does itself anyway.



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

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

[jira] [Created] (LUCENE-7043) add BigIntegerPoint and InetAddressPoint to sandbox

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7043:
---

 Summary: add BigIntegerPoint and InetAddressPoint to sandbox
 Key: LUCENE-7043
 URL: https://issues.apache.org/jira/browse/LUCENE-7043
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


We can now index 128-bit quantities, but still, making Fields for these is a 
bit of work: you have to do some numericutils sign-extension/sign-flipping 
magic for BigInteger quantities, deal with ipv4-mapped ipv6 addresses, etc.

We can just provide some simple field types that also have static factory 
methods for exact match/ranges.

The BigIntegerPoint is N-dimensional, so acts just like any other primitive, 
except its bigger (e.g. long long).

InetAddressPoint is 1-dimensional by nature: of course you can have multiple 
values per field, thats different. Since we prefix-compress values, we can just 
map IPv4 addresses to IPv6 space and it works for both types. This is 
consistent with what InetAddress does itself anyway.



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

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 856 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/856/

52 tests failed.
FAILED:  org.apache.solr.DistributedIntervalFacetingTest.test

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:51639//collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:51639//collection1
at 
__randomizedtesting.SeedInfo.seed([A03979645594375A:286D46BEFB685AA2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:544)
at 
org.apache.solr.DistributedIntervalFacetingTest.test(DistributedIntervalFacetingTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:990)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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 

[jira] [Commented] (SOLR-6846) deadlock in UninvertedField#getUninvertedField()

[Prasanna Ranganathan (JIRA)]

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

Prasanna Ranganathan commented on SOLR-6846:


I was looking into heap/memory leak issues on our Solr nodes and found the same 
symptom with many threads stuck on cache.wait() call when analyzing the heap 
dump. I think the issue is caused by the following:

{quote}
uif = new UnInvertedField(field, searcher);
{quote}

The above constructor can throw an IOException. If there happens to be any 
exception thrown in the constructor then there will be a bunch of threads stuck 
on the cache.wait() call. Hence the exception needs to be caught and re-thrown 
after clearing the placeholder object and notifying all the waiting threads.

> deadlock in UninvertedField#getUninvertedField()
> 
>
> Key: SOLR-6846
> URL: https://issues.apache.org/jira/browse/SOLR-6846
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.10.2
>Reporter: Avishai Ish-Shalom
> Fix For: 5.0, master
>
> Attachments: SOLR-6846.patch
>
>
> Multiple concurrent calls to UninvertedField#getUninvertedField may deadlock: 
> if a call gets to {{cache.wait()}} before another thread gets to the 
> synchronized block around {{cache.notifyAll()}} code will deadlock because 
> {{cache.wait()}} is synchronized with the same monitor object.



--
This message was sent by Atlassian 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-trunk-Linux (64bit/jdk-9-ea+106) - Build # 15966 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15966/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseG1GC

6 tests failed.
FAILED:  
org.apache.lucene.codecs.asserting.TestAssertingDocValuesFormat.testSortedSetFixedLengthVsStoredFields

Error Message:
Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/J1/temp/lucene.codecs.asserting.TestAssertingDocValuesFormat_295EC5980D2B13D0-001/dvduel-024/_6_Asserting_0.doc")

Stack Trace:
java.io.IOException: Unable to unmap the mapped buffer: 
MMapIndexInput(path="/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/test/J1/temp/lucene.codecs.asserting.TestAssertingDocValuesFormat_295EC5980D2B13D0-001/dvduel-024/_6_Asserting_0.doc")
at 
__randomizedtesting.SeedInfo.seed([295EC5980D2B13D0:5C2D74541AD64B86]:0)
at 
org.apache.lucene.store.MMapDirectory.lambda$initUnmapHack$1(MMapDirectory.java:384)
at 
org.apache.lucene.store.ByteBufferIndexInput.freeBuffer(ByteBufferIndexInput.java:376)
at 
org.apache.lucene.store.ByteBufferIndexInput.close(ByteBufferIndexInput.java:355)
at 
org.apache.lucene.util.LuceneTestCase.slowFileExists(LuceneTestCase.java:2662)
at 
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:732)
at 
org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:94)
at 
org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:94)
at 
org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:94)
at 
org.apache.lucene.codecs.lucene50.Lucene50CompoundFormat.write(Lucene50CompoundFormat.java:90)
at 
org.apache.lucene.index.IndexWriter.createCompoundFile(IndexWriter.java:4680)
at 
org.apache.lucene.index.DocumentsWriterPerThread.sealFlushedSegment(DocumentsWriterPerThread.java:496)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:460)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
at 
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2815)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
at 
org.apache.lucene.index.RandomIndexWriter.commit(RandomIndexWriter.java:288)
at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestSortedSetVsStoredFields(BaseDocValuesFormatTestCase.java:1983)
at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testSortedSetFixedLengthVsStoredFields(BaseDocValuesFormatTestCase.java:2047)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 

[jira] [Resolved] (SOLR-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

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

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

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
This message was sent by Atlassian 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-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8666:
---

bq.  it's possible the response is composed of stale data.

Eventually consistent :)

Good idea - only glanced at the patch, but looks good.

> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



--
This message was sent by Atlassian 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-8696) Optimize overseer + startup

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8696:
---

I think we should break up these two changes. Can we fix the nasty overseer 
init on reconnect bug here and open another to continue on the explicit state 
update?

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
This message was sent by Atlassian 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-5.5-Linux (64bit/jdk-9-ea+106) - Build # 83 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/83/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals

Error Message:
9

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 9
at 
__randomizedtesting.SeedInfo.seed([BF2627FF614F2E18:B1CFDC36D06F31B]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.LuceneTestCase.assertTermsEquals(LuceneTestCase.java:1964)
at 
org.apache.lucene.util.LuceneTestCase.assertFieldsEquals(LuceneTestCase.java:1926)
at 
org.apache.lucene.util.LuceneTestCase.assertTermVectorsEquals(LuceneTestCase.java:2349)
at 
org.apache.lucene.util.LuceneTestCase.assertReaderEquals(LuceneTestCase.java:1890)
at 
org.apache.lucene.index.TestDuelingCodecs.testCrazyReaderEquals(TestDuelingCodecs.java:172)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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:804)




Build Log:
[...truncated 981 lines...]
   [junit4] 

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:49566/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:49566/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([FB2ED6FA8E12B35D:41FCB9820D3C5D48]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:92)
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)

[jira] [Commented] (LUCENE-7015) Refactor spatial module to spatial-extras

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7015:


Thanks Nick, LGTM.

A couple nits:

* Your patch includes import/whitespace-trimming-only changes 4 Solr .java 
files - those changes should be made elsewhere, not on this issue.
* In {{spatial-extras/build.xml}}, the "spatialextrasjar" path id is a 
misnomer, should be spatial4j-jar or something like that (in spatial module 
it's currently named "spatialjar")
* In {{spatial-extras/build.xml}}: spatial4j-tests.jar should go to test-lib/ 
instead of lib/ (note that this same issue was present in the spatial module, 
I'm fine with leaving this as-is for this JIRA).


> Refactor spatial module to spatial-extras
> -
>
> Key: LUCENE-7015
> URL: https://issues.apache.org/jira/browse/LUCENE-7015
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
>Priority: Blocker
>  Labels: blocker
> Fix For: 6.0
>
> Attachments: LUCENE-7015.patch, LUCENE-7015.patch
>
>
> Follow on to LUCENE-6997: non GeoPoint* classes need to be refactored from 
> existing spatial module to a new spatial-extras module. All dev-tools, build 
> and project files will be updated to correctly reference and build the new 
> module.



--
This message was sent by Atlassian 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-8349) Allow sharing of large in memory data structures across cores

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8349:
--

bq.but I think there might be some holes WRT decoders decoding the same content 
more than once when multiple cores are loaded,

You can easily solve it by synchronizing the {{decode()}} code at your end

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
>Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



--
This message was sent by Atlassian 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-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8349:


Looked at the patch some today, Mostly it looks easy enough to adapt to my 
client's code, but I think there might be some holes WRT decoders decoding the 
same content more than once when multiple cores are loaded, and it seems we 
hold onto the ByteBuffer after the decoding, which doubles memory usage. Will 
comment more and provide suggestions (+ patch) tomorrow. Since decoding our 
file takes significant time and pegs the cpu's, I really don't want that 
repeating itself for all 40 cores :).

Loading code in my decoder will look something like this:
{code}
  ForkJoinPool pool = new 
ForkJoinPool(Runtime.getRuntime().availableProcessors());
  try (Stream lines = new BufferedReader(new 
InputStreamReader(inputStream, Charset.forName("UTF-8"))).lines()) {
try {
  pool.submit(() -> 
lines.parallel().forEach(this::processSimpleCsvRow)).get();
} catch (InterruptedException | ExecutionException e) {
  throw new IOException(e);
}
  } catch (IOException e) {
throw new RuntimeException("Cannot load  csv " , e);
  } finally {
pool.shutdownNow();
  }
{code}


> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
>Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



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

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

[jira] [Closed] (SOLR-8718) Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-8718.
-
   Resolution: Fixed
Fix Version/s: master

> Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location
> 
>
> Key: SOLR-8718
> URL: https://issues.apache.org/jira/browse/SOLR-8718
> Project: Solr
>  Issue Type: Task
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Trivial
> Fix For: master
>
> Attachments: SOLR-8718.patch
>
>
> The note for SOLR-8666
> {code}
> * SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
> PingRequestHandler to notify the client when a connection to zookeeper has 
> been lost and there is a possibility of stale data on the node the request is 
> coming from. (Keith Laban, Dennis Gove)
> {code}
> was put under bug fixes but it should have been put under improvements. This 
> ticket is to track the move of that note.



--
This message was sent by Atlassian 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-8718) Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location

[Dennis Gove (JIRA)]

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

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

> Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location
> 
>
> Key: SOLR-8718
> URL: https://issues.apache.org/jira/browse/SOLR-8718
> Project: Solr
>  Issue Type: Task
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Trivial
> Attachments: SOLR-8718.patch
>
>
> The note for SOLR-8666
> {code}
> * SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
> PingRequestHandler to notify the client when a connection to zookeeper has 
> been lost and there is a possibility of stale data on the node the request is 
> coming from. (Keith Laban, Dennis Gove)
> {code}
> was put under bug fixes but it should have been put under improvements. This 
> ticket is to track the move of that note.



--
This message was sent by Atlassian 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-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8718: Corrects location for note for SOLR-8666 in solr/CHANGES.txt


> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



--
This message was sent by Atlassian 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-8718) Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8718: Corrects location for note for SOLR-8666 in solr/CHANGES.txt


> Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location
> 
>
> Key: SOLR-8718
> URL: https://issues.apache.org/jira/browse/SOLR-8718
> Project: Solr
>  Issue Type: Task
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Trivial
>
> The note for SOLR-8666
> {code}
> * SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
> PingRequestHandler to notify the client when a connection to zookeeper has 
> been lost and there is a possibility of stale data on the node the request is 
> coming from. (Keith Laban, Dennis Gove)
> {code}
> was put under bug fixes but it should have been put under improvements. This 
> ticket is to track the move of that note.



--
This message was sent by Atlassian 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-8377) Unnecessary for loop in ReplicaAssigner.tryAllPermutations()

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-8377.
--
   Resolution: Fixed
Fix Version/s: 6.0

> Unnecessary for loop in ReplicaAssigner.tryAllPermutations()
> 
>
> Key: SOLR-8377
> URL: https://issues.apache.org/jira/browse/SOLR-8377
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: 1.patch
>
>
> Unused for loop in ReplicaAssigner.tryAllPermutations().



--
This message was sent by Atlassian 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-8377) Unnecessary for loop in ReplicaAssigner.tryAllPermutations()

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8377 removed an unnecessary for loop


> Unnecessary for loop in ReplicaAssigner.tryAllPermutations()
> 
>
> Key: SOLR-8377
> URL: https://issues.apache.org/jira/browse/SOLR-8377
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Assignee: Noble Paul
>Priority: Minor
> Attachments: 1.patch
>
>
> Unused for loop in ReplicaAssigner.tryAllPermutations().



--
This message was sent by Atlassian 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-5.5 - Build # 12 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/12/

No tests ran.

Build Log:
[...truncated 39775 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [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-5.5/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-5.5.0-src.tgz...
   [smoker] 28.7 MB in 0.03 sec (840.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.tgz...
   [smoker] 63.4 MB in 0.08 sec (822.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.0.zip...
   [smoker] 73.9 MB in 0.09 sec (818.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 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]   Backcompat testing not required for release 5.5.0 because 
it's not less than 5.5.0
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (164.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.0-src.tgz...
   [smoker] 37.5 MB in 0.37 sec (100.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.tgz...
   [smoker] 130.4 MB in 1.35 sec (96.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.0.zip...
   [smoker] 138.3 MB in 1.33 sec (104.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.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-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker] test solr example w/ Java 7...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.0-java7/solr-example.log)...
   [smoker] No process 

[jira] [Created] (SOLR-8718) Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-8718:
-

 Summary: Note for SOLR-8666 in solr/CHANGES.txt was put in the 
wrong location
 Key: SOLR-8718
 URL: https://issues.apache.org/jira/browse/SOLR-8718
 Project: Solr
  Issue Type: Task
Reporter: Dennis Gove
Assignee: Dennis Gove
Priority: Trivial


The note for SOLR-8666
{code}
* SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
PingRequestHandler to notify the client when a connection to zookeeper has been 
lost and there is a possibility of stale data on the node the request is coming 
from. (Keith Laban, Dennis Gove)
{code}
was put under bug fixes but it should have been put under improvements. This 
ticket is to track the move of that note.



--
This message was sent by Atlassian 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-5.5-Linux (32bit/jdk-9-ea+106) - Build # 82 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/82/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseG1GC

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=13109, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=13113, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)3) Thread[id=13110, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)4) Thread[id=13111, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)5) Thread[id=13112, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2106)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1131)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:804)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=13109, name=apacheds, state=WAITING, 
group=TGRP-SaslZkACLProviderTest]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=13113, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at 

[jira] [Updated] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Dennis Gove (JIRA)]

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

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

New patch with slightly updated test. This now causes an exception due to an 
invalid url instead of a DNS failure. It exposes the same issue being fixed and 
the test shows that the patch does in fact resolve it.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Comment Edited] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-8599 at 2/23/16 12:35 AM:
-

New patch with slightly updated test. This now causes an exception due to an 
invalid url instead of a DNS failure. It exposes the same issue being fixed and 
the test shows that the patch does in fact resolve it. This patch is what was 
committed in 2c0a5e30364d83dc82383075a5f7c65200022494.


was (Author: dpgove):
New patch with slightly updated test. This now causes an exception due to an 
invalid url instead of a DNS failure. It exposes the same issue being fixed and 
the test shows that the patch does in fact resolve it.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Resolved] (LUCENE-7042) more cleanup for Point encodings

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7042.
-
   Resolution: Fixed
Fix Version/s: 6.0

> more cleanup for Point encodings
> 
>
> Key: LUCENE-7042
> URL: https://issues.apache.org/jira/browse/LUCENE-7042
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7042.patch
>
>
> Followup of LUCENE-7039.
> I started consolidating encode/decode functions into XYZField, but its still 
> pretty messy. Specifically, duplicated code because indexer wants packed 
> byte[] and queries want byte[][] and so on.
> We can do a bit more cleanup: by defining everything in terms of 
> encodeDimension() and decodeDimension(). This way, the logic is only in one 
> place. 
> Also the new NumericUtils methods here are confusing I think. Its scary how 
> they take a "dimensional index" when parsing from a byte[]. I think they 
> should just take 'offset' and not try to be fancy, its easier to understand.



--
This message was sent by Atlassian 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-7039) Improve PointRangeQuery & co

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7039.
-
   Resolution: Fixed
Fix Version/s: 6.0

> Improve PointRangeQuery & co
> 
>
> Key: LUCENE-7039
> URL: https://issues.apache.org/jira/browse/LUCENE-7039
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7039.patch, LUCENE-7039.patch
>
>
> The point types are now preferred for indexing numeric fields, but 
> PointRangeQuery has some usability issues.
> I think we should make the following changes:
> * {{newIntRange()}}, {{newLongRange()}}, 
> {{newFloatRange()}},{{newDoubleRange()}}, {{newBinaryRange()}}: simple 1D 
> ranges consistent with NumericRangeQuery naming. 
> * {{newMultiIntRange()}}, {{newMultiLongRange()}}, {{newMultiFloatRange()}}, 
> {{newMultiDoubleRange()}}, {{newMultiBinaryRange()}}: multi-dimensional 
> versions of the above (take arrays, a bit harder to use, but the arrays have 
> correct type!)
> * {{toString()}} should be meaningful, it should not spew binary nonsense 
> unless you used a binary range!
> * improve javadocs
> If we like this, we could do similar improvements for the ExactPointQuery



--
This message was sent by Atlassian 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-7042) more cleanup for Point encodings

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7042: more cleanup for Point encodings


> more cleanup for Point encodings
> 
>
> Key: LUCENE-7042
> URL: https://issues.apache.org/jira/browse/LUCENE-7042
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7042.patch
>
>
> Followup of LUCENE-7039.
> I started consolidating encode/decode functions into XYZField, but its still 
> pretty messy. Specifically, duplicated code because indexer wants packed 
> byte[] and queries want byte[][] and so on.
> We can do a bit more cleanup: by defining everything in terms of 
> encodeDimension() and decodeDimension(). This way, the logic is only in one 
> place. 
> Also the new NumericUtils methods here are confusing I think. Its scary how 
> they take a "dimensional index" when parsing from a byte[]. I think they 
> should just take 'offset' and not try to be fancy, its easier to understand.



--
This message was sent by Atlassian 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-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8599:
---

Thanks. I'll keep that in mind going forward - and I agree, depending on a DNS 
failure was ripe for issues down the road. As the test was changed to instead 
rely on an invalid url I think what's in there will be good. New attachment 
forthcoming.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Assigned] (SOLR-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[Dennis Gove (JIRA)]

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

Dennis Gove reassigned SOLR-8666:
-

Assignee: Dennis Gove

> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



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

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

[jira] [Assigned] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Dennis Gove (JIRA)]

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

Dennis Gove reassigned SOLR-8599:
-

Assignee: Dennis Gove

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8599: After a failed connection during construction of SolrZkClient 
attempt to retry until a connection can be made


> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Commented] (SOLR-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
PingRequestHandler

Header is used to notify the client when a connection to zookeeper has been 
lost and there is a possibility of stale data on the node the request is coming 
from.


> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



--
This message was sent by Atlassian 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-8696) Optimize overseer + startup

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8696:
---

The history of legacy mode:

Initially, we had no collections API. Collections were created by a SolrCore 
registering with ZK and doing state updates. This allowed you to pre-configure 
SolrCores in solr.xml as you could with non SolrCloud. It was basically a way 
to quickly get going. But it has many problems.

Eventually we got the collections API and for back compat reasons added the 
legacyMode property. When not in legacy mode, state updates will not created 
collections - you must explicitly use the collections API. It's the start of 
what we call "zookeeper=truth" though currently only a small part of that is 
implemented.

> Optimize overseer + startup
> ---
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



--
This message was sent by Atlassian 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-8717) Our retry policy can also retry on HEAD and OPTION.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8717:
-

 Summary: Our retry policy can also retry on HEAD and OPTION.
 Key: SOLR-8717
 URL: https://issues.apache.org/jira/browse/SOLR-8717
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor






--
This message was sent by Atlassian 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-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8692:
--

thanks [~steve_rowe] 

> Move out embedded  json in ConfigOverlay and RuleBasedAuthorizationPlugin 
> --
>
> Key: SOLR-8692
> URL: https://issues.apache.org/jira/browse/SOLR-8692
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8692.patch
>
>




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

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

[jira] [Assigned] (SOLR-8377) Unnecessary for loop in ReplicaAssigner.tryAllPermutations()

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-8377:


Assignee: Noble Paul

> Unnecessary for loop in ReplicaAssigner.tryAllPermutations()
> 
>
> Key: SOLR-8377
> URL: https://issues.apache.org/jira/browse/SOLR-8377
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Assignee: Noble Paul
>Priority: Minor
> Attachments: 1.patch
>
>
> Unused for loop in ReplicaAssigner.tryAllPermutations().



--
This message was sent by Atlassian 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-8692) Move out embedded json in ConfigOverlay and RuleBasedAuthorizationPlugin

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8692: Deal with the new solr/core/src/resources/ dir: 1) add Maven config; 
and 2) improve IntelliJ config by using a new content root in solr-core module 
pointing to the resources dir, rather than using module-library declarations in 
the solr-core, solr-core-tests and solrj modules.


> Move out embedded  json in ConfigOverlay and RuleBasedAuthorizationPlugin 
> --
>
> Key: SOLR-8692
> URL: https://issues.apache.org/jira/browse/SOLR-8692
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8692.patch
>
>




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

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

[jira] [Commented] (SOLR-8375) ReplicaAssigner rejects valid positions

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8375:
--

[~kelvin.tan] This fix looks fine . could you give me a rule+ state combination 
for a testcase?

> ReplicaAssigner rejects valid positions
> ---
>
> Key: SOLR-8375
> URL: https://issues.apache.org/jira/browse/SOLR-8375
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Priority: Minor
> Attachments: SOLR-8375.patch, patch.txt
>
>
> ReplicaAssigner rejects any position for which a rule does not return 
> NODE_CAN_BE_ASSIGNED.
> However, if the rule's shard does not apply to the position's shard, Rule 
> returns NOT_APPLICABLE. This is not taken into account, and thus valid rules 
> are being rejected at the moment. 



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

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

[jira] [Assigned] (SOLR-8375) ReplicaAssigner rejects valid positions

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-8375:


Assignee: Noble Paul

> ReplicaAssigner rejects valid positions
> ---
>
> Key: SOLR-8375
> URL: https://issues.apache.org/jira/browse/SOLR-8375
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-8375.patch, patch.txt
>
>
> ReplicaAssigner rejects any position for which a rule does not return 
> NODE_CAN_BE_ASSIGNED.
> However, if the rule's shard does not apply to the position's shard, Rule 
> returns NOT_APPLICABLE. This is not taken into account, and thus valid rules 
> are being rejected at the moment. 



--
This message was sent by Atlassian 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-8375) ReplicaAssigner rejects valid positions

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8375:
-
Attachment: SOLR-8375.patch

> ReplicaAssigner rejects valid positions
> ---
>
> Key: SOLR-8375
> URL: https://issues.apache.org/jira/browse/SOLR-8375
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Kelvin Tan
>Priority: Minor
> Attachments: SOLR-8375.patch, patch.txt
>
>
> ReplicaAssigner rejects any position for which a rule does not return 
> NODE_CAN_BE_ASSIGNED.
> However, if the rule's shard does not apply to the position's shard, Rule 
> returns NOT_APPLICABLE. This is not taken into account, and thus valid rules 
> are being rejected at the moment. 



--
This message was sent by Atlassian 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-7042) more cleanup for Point encodings

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7042:


+1, thanks [~rcmuir]!

> more cleanup for Point encodings
> 
>
> Key: LUCENE-7042
> URL: https://issues.apache.org/jira/browse/LUCENE-7042
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7042.patch
>
>
> Followup of LUCENE-7039.
> I started consolidating encode/decode functions into XYZField, but its still 
> pretty messy. Specifically, duplicated code because indexer wants packed 
> byte[] and queries want byte[][] and so on.
> We can do a bit more cleanup: by defining everything in terms of 
> encodeDimension() and decodeDimension(). This way, the logic is only in one 
> place. 
> Also the new NumericUtils methods here are confusing I think. Its scary how 
> they take a "dimensional index" when parsing from a byte[]. I think they 
> should just take 'offset' and not try to be fancy, its easier to understand.



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

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

[jira] [Commented] (SOLR-8716) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8716:
-

I moved the issue to Solr. Please update the PR to use the correct issue number.

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



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

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

[jira] [Moved] (SOLR-8716) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler moved LUCENE-7041 to SOLR-8716:
-

Fix Version/s: (was: master)
   master
  Component/s: (was: general/build)
   contrib - Solr Cell (Tika extraction)
Lucene Fields:   (was: New)
  Key: SOLR-8716  (was: LUCENE-7041)
  Project: Solr  (was: Lucene - Core)

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



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

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

[jira] [Commented] (SOLR-8715) New Admin UI's Schema screen fails for some fields

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8715:
-

I think the cause is around fields that are *stored=false*, because it fails 
for *text* and *manu_exact*. But it does NOT fail for *text_rev*, which is also 
*stored=false*.

> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>  Labels: admin-interface
>
> In techproducts example, using new Admin UI and trying to load the Schema for 
> text field causes blank screen and the Javascript error in the developer 
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
> 
> {noformat}
> Tested with 5.5rc3



--
This message was sent by Atlassian 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-8715) New Admin UI's Schema screen fails for some fields

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-8715:
---

 Summary: New Admin UI's Schema screen fails for some fields
 Key: SOLR-8715
 URL: https://issues.apache.org/jira/browse/SOLR-8715
 Project: Solr
  Issue Type: Bug
  Components: UI
Affects Versions: 5.5
 Environment: mac, firefox
Reporter: Alexandre Rafalovitch


In techproducts example, using new Admin UI and trying to load the Schema for 
text field causes blank screen and the Javascript error in the developer 
console:

{noformat}
Error: row.flags is undefined
getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
$scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38

{noformat}

Tested with 5.5rc3



--
This message was sent by Atlassian 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-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8599 at 2/22/16 10:32 PM:
---

Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

FYI, {{ff01::}} is the address range for local Multicast addresses, but only 
{{::1}} (all local nodes) and {{::2}} (all routers) are allowed in IPv6 
networks. {{ff01::114}} is plain invalid and refused by host's TCP stack for 
using in TCP connections. So it is guaranteed to fail.


was (Author: thetaphi):
Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

FYI, {{ff01::}} is the address range for Multicast addresses, but only {{::1}} 
(all local nodes) and {{::2}} (all routers) are allowed in IPv6 networks. 
{{ff01::114}} is plain invalid and refused by host's TCP stack for using in TCP 
connections. So it is guaranteed to fail.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Comment Edited] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8599 at 2/22/16 10:32 PM:
---

Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

FYI, {{ff01::}} is the address range for local Multicast addresses, but only 
{{ff01::1}} (all local nodes) and {{ff01::2}} (all routers) are allowed in IPv6 
networks. {{ff01::114}} is plain invalid and refused by host's TCP stack for 
using in TCP connections. So it is guaranteed to fail.


was (Author: thetaphi):
Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

FYI, {{ff01::}} is the address range for local Multicast addresses, but only 
{{::1}} (all local nodes) and {{::2}} (all routers) are allowed in IPv6 
networks. {{ff01::114}} is plain invalid and refused by host's TCP stack for 
using in TCP connections. So it is guaranteed to fail.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Created] (LUCENE-7042) more cleanup for Point encodings

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7042:
---

 Summary: more cleanup for Point encodings
 Key: LUCENE-7042
 URL: https://issues.apache.org/jira/browse/LUCENE-7042
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Attachments: LUCENE-7042.patch

Followup of LUCENE-7039.

I started consolidating encode/decode functions into XYZField, but its still 
pretty messy. Specifically, duplicated code because indexer wants packed byte[] 
and queries want byte[][] and so on.

We can do a bit more cleanup: by defining everything in terms of 
encodeDimension() and decodeDimension(). This way, the logic is only in one 
place. 

Also the new NumericUtils methods here are confusing I think. Its scary how 
they take a "dimensional index" when parsing from a byte[]. I think they should 
just take 'offset' and not try to be fancy, its easier to understand.



--
This message was sent by Atlassian 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-7042) more cleanup for Point encodings

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7042:

Attachment: LUCENE-7042.patch

> more cleanup for Point encodings
> 
>
> Key: LUCENE-7042
> URL: https://issues.apache.org/jira/browse/LUCENE-7042
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7042.patch
>
>
> Followup of LUCENE-7039.
> I started consolidating encode/decode functions into XYZField, but its still 
> pretty messy. Specifically, duplicated code because indexer wants packed 
> byte[] and queries want byte[][] and so on.
> We can do a bit more cleanup: by defining everything in terms of 
> encodeDimension() and decodeDimension(). This way, the logic is only in one 
> place. 
> Also the new NumericUtils methods here are confusing I think. Its scary how 
> they take a "dimensional index" when parsing from a byte[]. I think they 
> should just take 'offset' and not try to be fancy, its easier to understand.



--
This message was sent by Atlassian 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-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8599 at 2/22/16 10:31 PM:
---

Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

FYI, {{ff01::}} is the address range for Multicast addresses, but only {{::1}} 
(all local nodes) and {{::2}} (all routers) are allowed in IPv6 networks. 
{{ff01::114}} is plain invalid and refused by host's TCP stack for using in TCP 
connections. So it is guaranteed to fail.


was (Author: thetaphi):
Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Comment Edited] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8599 at 2/22/16 10:27 PM:
---

Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr tests. For similar reasons we 
also do not use "localhost" as hostname, but instead use 127.0.0.1 as IP 
address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java


was (Author: thetaphi):
Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr. For similar reasons we also 
do not use "localhost" as hostname, but instead use 127.0.0.1 as IP address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8599:
-

Hi,
please don't write tests that rely on DNS failures. Every local provider does 
something else, but not all return a correct "not found". Unless we have a 
"mock DNS server", we cannot use any DNS in Solr. For similar reasons we also 
do not use "localhost" as hostname, but instead use 127.0.0.1 as IP address.

To have some broken address that always fails to connect to, use an IPv6 
address that is standardized to be routed nowhere and already refused by the 
Hosts's IPv6 stack. According to spec one possible address is: 
{{http://[ff01::114]:anyport/}}

As example look at SolrExceptionTest.java

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8599:
---

Yeah, we try to avoid that in tests due to dns hijacking. I think there is an 
ip6 address that works for this? [~thetaphi], am I remembering right?

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {code}



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

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

[jira] [Comment Edited] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7041 at 2/22/16 10:05 PM:
-

Pull request is fine. We will merge the pull request in, once all is fine. We 
attach the patch when mergin to the issue for reference, but for the work 
towards the commit, a simple PR is fine.


was (Author: thetaphi):
Pull request is fine. We will merge the pull request in, once all is fine.

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



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

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

RE: Adding New Module to Eclipse Packaging

[Uwe Schindler]

To add a new module, you have to first do the Ant/Ivy based setup (in general 
its simplest to copy another module) and then edit build.xml and ivy.xml to 
pull in dependencies. I assume your new module will depend on 
contrib/extraction, so you would need to make a dependency to the build.xml so 
it can build with ant. It is not needed for the eclipse setup (because 
Lucene/Solr uses one large classpath inside Eclipse and dependencies don’t 
exist), but for the final module deployment in Lucene’s ant/ivy build system, 
the setup must be correct. I am sorry, it is a bit complicated. Maybe we move 
to Gradle build at some point…

 

Once this is done, you can run “ant eclipse” and do what Shawn Heisey already 
said.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: lewis john mcgibbney [mailto:lewi...@apache.org] 
Sent: Monday, February 22, 2016 10:27 PM
To: dev@lucene.apache.org
Subject: Adding New Module to Eclipse Packaging

 

Hi dev@,

Been unable to implement the Eclipse configuration for a new module as of yet.

I see the configuration within dev-tools/eclipse and I have edited a number of 
idea and maven configuration but still unable to see the new packages when 
importing into Eclipse.

Can someone please point me to the code which defines the Eclipse packaging?\

Thank you very much.

lewis

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 855 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/855/

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

Error Message:
.response.numFound:1!=0

Stack Trace:
junit.framework.AssertionFailedError: .response.numFound:1!=0
at 
__randomizedtesting.SeedInfo.seed([73E05D3FAFE54643:FBB462E501192BBB]:0)
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:892)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:911)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryAndCompare(BaseDistributedSearchTestCase.java:654)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryAndCompareReplicas(AbstractFullDistribZkTestBase.java:1061)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryAndCompareShards(AbstractFullDistribZkTestBase.java:1078)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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 

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7041:
---

Pull request is fine. We will merge the pull request in, once all is fine.

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



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

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

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney commented on LUCENE-7041:
--

ACK, this guidance is very helpful. I've been picking my way through the Lucene 
and Solr build with interest, and yes your right the dependency soup which Tika 
brings is pretty much hellish. Regardless, I'll revisit this right now and make 
best efforts to get an update patch through to you. Can I also please ask, 
which is the best method for providing the update? via patch or pull request on 
Github or both?
Thanks

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



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

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

[JENKINS-EA] Lucene-Solr-5.5-Linux (64bit/jdk-9-ea+106) - Build # 81 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/81/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.memory.TestMemoryPostingsFormat

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

Stack Trace:
java.lang.AssertionError: The test or suite printed 11784 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([F21D8556605F9927]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.lucene.codecs.bloom.TestBloomPostingsFormat.testDocsAndFreqsAndPositions

Error Message:
Captured an uncaught exception in thread: Thread[id=548, name=Thread-527, 
state=RUNNABLE, group=TGRP-TestBloomPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=548, name=Thread-527, state=RUNNABLE, 
group=TGRP-TestBloomPostingsFormat]
at 
__randomizedtesting.SeedInfo.seed([F21D8556605F9927:E83E31C798BC9923]:0)
Caused by: java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 9
at __randomizedtesting.SeedInfo.seed([F21D8556605F9927]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 9
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1166)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)


FAILED:  
org.apache.lucene.codecs.memory.TestMemoryPostingsFormat.testDocsAndFreqsAndPositions

Error Message:
Captured an uncaught exception in thread: Thread[id=616, name=Thread-595, 
state=RUNNABLE, group=TGRP-TestMemoryPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=616, name=Thread-595, state=RUNNABLE, 
group=TGRP-TestMemoryPostingsFormat]
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: 
source=3 is out of bounds (maxState is 2)
at __randomizedtesting.SeedInfo.seed([F21D8556605F9927]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.IllegalArgumentException: source=3 is out of bounds 
(maxState is 2)
at 
org.apache.lucene.util.automaton.Automaton.addTransition(Automaton.java:167)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:245)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:537)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:614)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:614)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:614)
at 

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7041:
---

Hi Lewis,
unfortunately, your patch is not enough! Lucene does not use transitive 
dependecies anywhere. So when you update TIKA, you also have to verify the 
dependencies of TIKA and update the other versions listed in ivy-versions.xml 
to the ones that are required by TIKA (e.g. PDFBOX, ROME,...). Not doing this 
will make the tests of the contrib/extraction module to fail.

To test the upgrade, you must run "ant test" inside the contrib/extraction 
module.

Please also make sure to update PDFBOX to one newer than the one required by 
TIKA, because we need the BUG in PDFBOX to be fixed, that makes it not work 
with Java 9 (Lucene and Solr tests must pass with Java 9 previews). The version 
currently shipped with TIKA 1.12 is broken, unfortunately.

The hard part in updating is:
- You have to be sure that you don't upgrade a library required by TIKA that 
Solr needs in another/older version (there are several ones). We generally 
disable those parsers that require incorrect versions.
- If you really need to upgrade some library required for TIKA and we must 
update Solr's shared one, it gets complicated and needs a lot of testing, so it 
should generally be avoided. This is the reason why TIKA gets updated sparingly 
in Solr. The dependency-hell as introduced by TIKA is horrible for us to manage 
- in fact its a desaster!

{noformat}
Trivial update. @uschindler I attempted running ant test locally with the 
following failures
   [junit4] Suite: org.apache.solr.search.TestSolrJ
   [junit4] Completed [579/579 (6!)] on J3 in 0.02s, 1 test
   [junit4]
   [junit4]
   [junit4] Tests with failures [seed: 64AD6FE9325CC7B0]:
   [junit4]   - org.apache.solr.cloud.TestRequestStatusCollectionAPI.test
   [junit4]   - org.apache.solr.cloud.DistribCursorPagingTest.test
   [junit4]   - org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.test
   [junit4]   - org.apache.solr.cloud.SimpleCollectionCreateDeleteTest.test
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testSegmentTerminateEarly
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete
   [junit4]   - 
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDir
   [junit4]   - org.apache.solr.handler.admin.CoreAdminHandlerTest (suite)
   [junit4]
   [junit4]
   [junit4] JVM J0: 0.60 ..   655.76 =   655.16s
   [junit4] JVM J1: 0.85 ..   656.59 =   655.74s
   [junit4] JVM J2: 0.85 ..   200.28 =   199.44s
   [junit4] JVM J3: 0.60 ..  1037.32 =  1036.72s
   [junit4] Execution time total: 17 minutes 17 seconds
   [junit4] Tests summary: 579 suites (8 ignored), 2331 tests, 2 suite-level 
errors, 8 errors, 1 failure, 1320 ignored (59 assumptions)

BUILD FAILED
/usr/local/lucene-solr/build.xml:59: The following error occurred while 
executing this line:
/usr/local/lucene-solr/solr/build.xml:233: The following error occurred while 
executing this line:
/usr/local/lucene-solr/solr/common-build.xml:524: The following error occurred 
while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1457: The following error 
occurred while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1014: There were test failures: 
579 suites (8 ignored), 2331 tests, 2 suite-level errors, 8 errors, 1 failure, 
1320 ignored (59 assumptions) [seed: 64AD6FE9325CC7B0]

Total time: 34 minutes 7 seconds
{noformat}

These are unrelated failures in the Solr core module. You should run tests in 
contrib/extraction only as a start. Fixing your whole test setup to make 
everything work can be done afterwards.

I assume you never ran tests in contrib/extraction, because it failed already 
before. I am quite sure that contrib/extraction will fail completely because of 
the non-yet updated dependencies.

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



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

Re: Adding New Module to Eclipse Packaging

[Shawn Heisey]

On 2/22/2016 2:26 PM, lewis john mcgibbney wrote:
> Been unable to implement the Eclipse configuration for a new module as
> of yet.
> I see the configuration within dev-tools/eclipse and I have edited a
> number of idea and maven configuration but still unable to see the new
> packages when importing into Eclipse.
> Can someone please point me to the code which defines the Eclipse
> packaging?\
>

Some of this info may not be new to you, but I'm including it for others
who might need it.

What I do to import lucene-solr into eclipse:

complete the git clone.
cd to the new directory.
if necessary, switch branches.
run "ant clean eclipse"

Once the ant command finishes, open eclipse.  Right-click on a blank
spot in the project explorer, choose "Import", then "Import..." (with
three dots).  Under General, choose "Existing Projects into Workspace". 
Use the "browse" button to find the location and click OK.  Eclipse
should find the project.  Make sure the correct project has a check in
its box, then click the Finish button.

After it is imported, click once on the project in the project explorer
and refresh the project.  I use the F5 key for this, but you can also
right-click on the project and choose Refresh from the menu.  Eclipse
will start a full build of the project.

If new source files are added, they should show up either immediately or
after you refresh the project.

When pulling updates to your local working copy from the git server, or
if you make changes to the ivy configuration, I recommend closing
eclipse, running the following command, re-opening eclipse, and
repeating the refresh:

ant clean clean-jars clean-eclipse eclipse

Thanks,
Shawn


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

Re: Adding New Module to Eclipse Packaging

[lewis john mcgibbney]

OK I've sorted this out now.
Not sure exactly how or when I got it working but I just made replicas of
build.xml and ivy.xml from an existing module then cleaned the Eclipse
environment cache and refreshed the workspace.
That seemed to do it :)

On Mon, Feb 22, 2016 at 1:26 PM, lewis john mcgibbney 
wrote:

> Hi dev@,
> Been unable to implement the Eclipse configuration for a new module as of
> yet.
> I see the configuration within dev-tools/eclipse and I have edited a
> number of idea and maven configuration but still unable to see the new
> packages when importing into Eclipse.
> Can someone please point me to the code which defines the Eclipse
> packaging?\
> Thank you very much.
> lewis
>

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

[Policeman Jenkins Server]

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

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

Error Message:
Captured an uncaught exception in thread: Thread[id=5563, 
name=testExecutor-2456-thread-4, state=RUNNABLE, 
group=TGRP-UnloadDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5563, name=testExecutor-2456-thread-4, 
state=RUNNABLE, group=TGRP-UnloadDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:39174
at __randomizedtesting.SeedInfo.seed([AE6C9F49A2999C08]:0)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:586)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured 
while waiting response from server at: http://127.0.0.1:39174
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.BasicDistributedZkTest$1.run(BasicDistributedZkTest.java:584)
... 4 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:482)
... 8 more




Build Log:
[...truncated 11266 lines...]
   [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_AE6C9F49A2999C08-001/init-core-data-001
   [junit4]   2> 592847 INFO  
(SUITE-UnloadDistributedZkTest-seed#[AE6C9F49A2999C08]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 592851 INFO  
(TEST-UnloadDistributedZkTest.test-seed#[AE6C9F49A2999C08]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 592852 INFO  (Thread-2021) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 592852 INFO  (Thread-2021) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 592952 INFO  

Adding New Module to Eclipse Packaging

[lewis john mcgibbney]

Hi dev@,
Been unable to implement the Eclipse configuration for a new module as of
yet.
I see the configuration within dev-tools/eclipse and I have edited a number
of idea and maven configuration but still unable to see the new packages
when importing into Eclipse.
Can someone please point me to the code which defines the Eclipse
packaging?\
Thank you very much.
lewis

[jira] [Updated] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney updated LUCENE-7041:
-
Attachment: LUCENE-7041.patch

Git-generated patch. This is trivial but as mentioned over on [0] I am getting 
failing tests locally. 

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

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



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

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

[jira] [Comment Edited] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney edited comment on LUCENE-7041 at 2/22/16 9:17 PM:
---

Running test suite just now, this looks to be a very trivial patch but will be 
really cool when we can do language translation when indexing documents. 
[~thetaphi], thanks for assigning yourself to this one. 


was (Author: lewismc):
Running test suit just now, this looks to be a very trivial patch but will be 
really cool when we can do language translation when indexing documents. 
[~thetaphi], thanks for assigning yourself to this one. 

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



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

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

Re: git email format customizability: add branch to subject?

[Chris Hostetter]

: +1 for keeping the repo name but perhaps we could drop the "git: " prefix?
: 
: Without the prefix the subject would still be fairly distinguishable 
: from the "svn commit" emails such as "svn commit: r1731559 - 
: /lucene/cms/trunk/content/extpaths.txt" (assuming the svn commit emails 
: keep their existing format).

My concern was that w/o "git" explicitly in the subject somewhere, it 
would be hard to setup simple filter rules for some folks since
"lucene-solr" can appear in other subjects ... but i suppose the fact that 
we have an explicit commits@lucene list for these emails makes that 
concern moot since that can be part of whatever filter rule folks might 
use.

Anybody else feel strongly about leaving "git:" in the subject?

: Looks good to me. I'd keep the repo name regardless of whether it's
: the main repo or not.

I agree -- i know a lot of people who work on multiple projects but filter 
all "commit" related emails to a single folder, nd being able to tell at a 
glance which projust a message refers to is useful (let alone if/when we 
add future git repos)

Any other concerns/opinions before i mover forward with contacting infra?



One other thing i recently realized is that tag creation notification 
emails don't seem to follow the current pattern at all, note this email...

Subject: [lucene-solr] Git Push Summary
http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3c4bb21471466f4701ba9452b739acb...@git.apache.org%3E

...I'll ask infra about getting those to conform to the same 
subject pattern. 







-Hoss
http://www.lucidworks.com/

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

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

[lewismc]

GitHub user lewismc opened a pull request:

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

LUCENE-7041 Upgrade to Apache Tika 1.12

Trivial update. @uschindler I attempted running ant test locally with the 
following failures
```
   [junit4] Suite: org.apache.solr.search.TestSolrJ
   [junit4] Completed [579/579 (6!)] on J3 in 0.02s, 1 test
   [junit4]
   [junit4]
   [junit4] Tests with failures [seed: 64AD6FE9325CC7B0]:
   [junit4]   - org.apache.solr.cloud.TestRequestStatusCollectionAPI.test
   [junit4]   - org.apache.solr.cloud.DistribCursorPagingTest.test
   [junit4]   - 
org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.test
   [junit4]   - org.apache.solr.cloud.SimpleCollectionCreateDeleteTest.test
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testSegmentTerminateEarly
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete
   [junit4]   - 
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDir
   [junit4]   - org.apache.solr.handler.admin.CoreAdminHandlerTest (suite)
   [junit4]
   [junit4]
   [junit4] JVM J0: 0.60 ..   655.76 =   655.16s
   [junit4] JVM J1: 0.85 ..   656.59 =   655.74s
   [junit4] JVM J2: 0.85 ..   200.28 =   199.44s
   [junit4] JVM J3: 0.60 ..  1037.32 =  1036.72s
   [junit4] Execution time total: 17 minutes 17 seconds
   [junit4] Tests summary: 579 suites (8 ignored), 2331 tests, 2 
suite-level errors, 8 errors, 1 failure, 1320 ignored (59 assumptions)

BUILD FAILED
/usr/local/lucene-solr/build.xml:59: The following error occurred while 
executing this line:
/usr/local/lucene-solr/solr/build.xml:233: The following error occurred 
while executing this line:
/usr/local/lucene-solr/solr/common-build.xml:524: The following error 
occurred while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1457: The following error 
occurred while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1014: There were test 
failures: 579 suites (8 ignored), 2331 tests, 2 suite-level errors, 8 errors, 1 
failure, 1320 ignored (59 assumptions) [seed: 64AD6FE9325CC7B0]

Total time: 34 minutes 7 seconds
```

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

$ git pull https://github.com/lewismc/lucene-solr LUCENE-7041

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

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


commit 8a6fb261d9c4f7a3970be3bb928ab9ecccb387bc
Author: Lewis John McGibbney 
Date:   2016-02-22T21:08:49Z

LUCENE-7041 Upgrade to Apache Tika 1.12




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

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

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7041:


GitHub user lewismc opened a pull request:

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

LUCENE-7041 Upgrade to Apache Tika 1.12

Trivial update. @uschindler I attempted running ant test locally with the 
following failures
```
   [junit4] Suite: org.apache.solr.search.TestSolrJ
   [junit4] Completed [579/579 (6!)] on J3 in 0.02s, 1 test
   [junit4]
   [junit4]
   [junit4] Tests with failures [seed: 64AD6FE9325CC7B0]:
   [junit4]   - org.apache.solr.cloud.TestRequestStatusCollectionAPI.test
   [junit4]   - org.apache.solr.cloud.DistribCursorPagingTest.test
   [junit4]   - 
org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.test
   [junit4]   - org.apache.solr.cloud.SimpleCollectionCreateDeleteTest.test
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testSegmentTerminateEarly
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
   [junit4]   - 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete
   [junit4]   - 
org.apache.solr.handler.admin.CoreAdminHandlerTest.testDeleteInstanceDir
   [junit4]   - org.apache.solr.handler.admin.CoreAdminHandlerTest (suite)
   [junit4]
   [junit4]
   [junit4] JVM J0: 0.60 ..   655.76 =   655.16s
   [junit4] JVM J1: 0.85 ..   656.59 =   655.74s
   [junit4] JVM J2: 0.85 ..   200.28 =   199.44s
   [junit4] JVM J3: 0.60 ..  1037.32 =  1036.72s
   [junit4] Execution time total: 17 minutes 17 seconds
   [junit4] Tests summary: 579 suites (8 ignored), 2331 tests, 2 
suite-level errors, 8 errors, 1 failure, 1320 ignored (59 assumptions)

BUILD FAILED
/usr/local/lucene-solr/build.xml:59: The following error occurred while 
executing this line:
/usr/local/lucene-solr/solr/build.xml:233: The following error occurred 
while executing this line:
/usr/local/lucene-solr/solr/common-build.xml:524: The following error 
occurred while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1457: The following error 
occurred while executing this line:
/usr/local/lucene-solr/lucene/common-build.xml:1014: There were test 
failures: 579 suites (8 ignored), 2331 tests, 2 suite-level errors, 8 errors, 1 
failure, 1320 ignored (59 assumptions) [seed: 64AD6FE9325CC7B0]

Total time: 34 minutes 7 seconds
```

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

$ git pull https://github.com/lewismc/lucene-solr LUCENE-7041

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

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


commit 8a6fb261d9c4f7a3970be3bb928ab9ecccb387bc
Author: Lewis John McGibbney 
Date:   2016-02-22T21:08:49Z

LUCENE-7041 Upgrade to Apache Tika 1.12




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



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

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

Re: [CONF] Apache Solr Reference Guide > Running Solr on HDFS

[Uwe Schindler]

Thanks!

Uwe

Am 22. Februar 2016 21:53:28 MEZ, schrieb "Hoss Man (Confluence)" 
:
>Hoss Man edited a page   Change comment: all lucene codec's are append
>only now   Running Solr on HDFS  View page•  Add comment•  Like   Stop
>watching space• Manage notifications   This message was sent by
>Atlassian Confluence 5.8.4
>  

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

[Chris Hostetter]

VOTE has passed, i'll begin pushing to mirrors.


: Date: Fri, 19 Feb 2016 16:05:18 -0700 (MST)
: From: Chris Hostetter 
: To: Lucene Dev 
: Cc: gene...@lucene.apache.org
: Subject: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf
: 
: 
: Please VOTE to release the following artifacts as
: apache-solr-ref-guide-5.5.pdf ...
: 
: 
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC1/
: 
: -Hoss
: http://www.lucidworks.com/
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney commented on LUCENE-7041:
--

agreed, the parsers module is getting very bulky in tTika these days so some 
dependency management is definitely required here. 

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



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

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

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7041:
---

Hi, I will help reviewing and committing the patch. There are some special 
cases because we only want a selection of parsers and we do not transitively 
grab all dependencies of Tika. So every new dependency should be reviewed.

Uwe

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



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

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

[jira] [Commented] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney commented on LUCENE-7041:
--

Running test suit just now, this looks to be a very trivial patch but will be 
really cool when we can do language translation when indexing documents. 
[~thetaphi], thanks for assigning yourself to this one. 

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



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

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

[jira] [Assigned] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned LUCENE-7041:
-

Assignee: Uwe Schindler

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



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

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

Re: ZK Connection Failure leads to stale data

[Dennis Gove]

David,

Thanks - I've been trying to get these in for a bit but have been running
into inconsistent test results described in
https://issues.apache.org/jira/browse/SOLR-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15157644#comment-15157644.


While I am able to get around it in this particular case, it does bring up
an interesting situation where there is a possibility of an infinite loop
while connecting to zookeeper if a DNS lookup fails and your ISP returns a
redirect instead of the expected DNS Failure.

- Dennis

On Wed, Feb 10, 2016 at 6:18 PM, david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:

> Both sound very good to me, Dennis. Thanks.
> On Wed, Feb 10, 2016 at 11:55 AM Dennis Gove  wrote:
>
>> Just wanted to take a moment to get anyone's thoughts on the following
>> issues
>>
>> https://issues.apache.org/jira/browse/SOLR-8599
>> https://issues.apache.org/jira/browse/SOLR-8666
>>
>> The originating problem occurred due to a DNS failure that caused some
>> nodes in a cloud setup to fail to connect to zookeeper. Those nodes were
>> running but were not participating in the cloud with the other nodes. The
>> disconnected nodes would respond to queries with stale data, though they
>> would reject injest requests.
>>
>> Ticket https://issues.apache.org/jira/browse/SOLR-8599 contains a patch
>> which ensures that if a connection to zookeeper fails to be made it will be
>> retried. Previously the failure wasn't leading to a retry so the node would
>> just run and be disconnect until the node itself was restarted.
>>
>> Ticket https://issues.apache.org/jira/browse/SOLR-8666 contains a patch
>> which will result in additional information returned to the client when a
>> node may be returning stale data due to not being connected to zookeeper.
>> The intent was to not change current behavior but allow the client to know
>> that something might be wrong. In situations where the collection is not
>> being updated the data may not be stale so it wouldn't matter if the node
>> is disconnected from zookeeper but in situations where the collection is
>> being updated then the data may be stale. The headers of the response will
>> now contain an entry to indicate this. Also, adds a header to the ping
>> response to also provide notification if the node is disconnected from
>> zookeeper.
>>
>> I think the approach these patches take are good but wanted to get
>> others' thoughts and perhaps I'm missing a case where these might cause a
>> problem.
>>
>> Thanks - Dennis
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

[jira] [Created] (LUCENE-7041) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

Lewis John McGibbney created LUCENE-7041:


 Summary: Upgrade to Apache Tika 1.12
 Key: LUCENE-7041
 URL: https://issues.apache.org/jira/browse/LUCENE-7041
 Project: Lucene - Core
  Issue Type: Improvement
  Components: general/build
Reporter: Lewis John McGibbney
 Fix For: master


We recently released Apache Tika 1.12. In order to use the fixes provided 
within the Tika.translate API I propose to upgrade Tika from 1.7 --> 1.12 in 
lucene/ivy-versions.properties.
Patch coming up.




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

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

[jira] [Commented] (SOLR-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8599:
---

I have somewhat of an interesting situation at hand here.

As part of this patch a test is added to ConnectionManagerTest which forces a 
DNS failure on the zookeeper connection by attempting to connect to 
"BADADDRESS" and then fixing it after 5 seconds. This shows that the change 
Keith put in ConnectionManager will continually try to make a connection until 
it can. It's a good test and it exercises the bug and fix perfectly.

However, the test depends on my ISP. I've run the test under 5 scenarios and 
only 3 of them pass. 

1. Connected to my corporate network
In this scenario the test passes perfectly as it should.

2. Connected to no network (ie, wifi card turned off)
In this scenario the test passes perfectly as it should.

3. Connected to my home network backed by Verizon FIOS
In this scenario the test hangs and upon further investigation I found that it 
is in an "infinite" loop in ConnectionManager::waitForConnected. This appears 
to be an infinite loop because while there is a timeout the timeout is 
Long.MAX_VALUE. The problem here is that the loop waits until it is either 
connected or closed. Neither of those conditions are ever hit. But why? We're 
trying to hit http://BADADDRESS and clearly that is a DNS lookup failure. Oh no 
no no, not according to Verizon. See, Verizon instead says "Oh, you must've 
typed something in wrong so instead of returning to you a DNS failure let me 
return to you a redirect to a search page - you clearly want this search page". 
It appears that because of this redirection a connection is never made nor is 
it ever closed. Hence, loop forever. 

4. Connected to my personal wifi hotspot backed by T-Mobile
Same issue as seen with Verizon FIOS, though a T-Mobile specific search page. 

5. Connected to a hotspot through my iPhone backed by Verizon Wireless
In this scenario the test passes perfectly as it should.

Note that this difference is *only* seen when a DNS lookup failure is in play. 
If I change the bad address to "http://BADADDRESS; then it fails instead 
because "//BADADDRESSIS" is said to be an invalid path string. Technically this 
is testing a slightly different case but I'm comfortable calling it the same 
test because the issue being corrected is a failure to make a connection during 
the construction of SolrZooKeeper and a malformed url fails just the same.


> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
> Attachments: SOLR-8599.patch, SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] 

[jira] [Commented] (LUCENE-7039) Improve PointRangeQuery & co

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7039: Improve PointRangeQuery & co


> Improve PointRangeQuery & co
> 
>
> Key: LUCENE-7039
> URL: https://issues.apache.org/jira/browse/LUCENE-7039
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-7039.patch, LUCENE-7039.patch
>
>
> The point types are now preferred for indexing numeric fields, but 
> PointRangeQuery has some usability issues.
> I think we should make the following changes:
> * {{newIntRange()}}, {{newLongRange()}}, 
> {{newFloatRange()}},{{newDoubleRange()}}, {{newBinaryRange()}}: simple 1D 
> ranges consistent with NumericRangeQuery naming. 
> * {{newMultiIntRange()}}, {{newMultiLongRange()}}, {{newMultiFloatRange()}}, 
> {{newMultiDoubleRange()}}, {{newMultiBinaryRange()}}: multi-dimensional 
> versions of the above (take arrays, a bit harder to use, but the arrays have 
> correct type!)
> * {{toString()}} should be meaningful, it should not spew binary nonsense 
> unless you used a binary range!
> * improve javadocs
> If we like this, we could do similar improvements for the ExactPointQuery



--
This message was sent by Atlassian 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-5.5-Linux (64bit/jdk-9-ea+106) - Build # 80 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/80/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.codecs.memory.TestMemoryPostingsFormat.testRandom

Error Message:
Captured an uncaught exception in thread: Thread[id=602, name=Thread-579, 
state=RUNNABLE, group=TGRP-TestMemoryPostingsFormat]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=602, name=Thread-579, state=RUNNABLE, 
group=TGRP-TestMemoryPostingsFormat]
at 
__randomizedtesting.SeedInfo.seed([A3531F208DDF387C:D11F3A2F3CBF8E0F]:0)
Caused by: java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 6
at __randomizedtesting.SeedInfo.seed([A3531F208DDF387C]:0)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 6
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
at org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1166)
at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)




Build Log:
[...truncated 6375 lines...]
   [junit4] Suite: org.apache.lucene.codecs.memory.TestMemoryPostingsFormat
   [junit4]   2> ???. 22, 2016 5:03:48 ?? 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-579,5,TGRP-TestMemoryPostingsFormat]
   [junit4]   2> java.lang.RuntimeException: 
java.lang.ArrayIndexOutOfBoundsException: 6
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([A3531F208DDF387C]:0)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1005)
   [junit4]   2> Caused by: java.lang.ArrayIndexOutOfBoundsException: 6
   [junit4]   2>at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
   [junit4]   2>at 
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:426)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomSingleAutomaton(AutomatonTestUtil.java:262)
   [junit4]   2>at 
org.apache.lucene.util.automaton.AutomatonTestUtil.randomAutomaton(AutomatonTestUtil.java:276)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.testTermsOneThread(RandomPostingsTester.java:1166)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester.access$000(RandomPostingsTester.java:62)
   [junit4]   2>at 
org.apache.lucene.index.RandomPostingsTester$TestThread.run(RandomPostingsTester.java:1003)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMemoryPostingsFormat -Dtests.method=testRandom 
-Dtests.seed=A3531F208DDF387C -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=uk-UA -Dtests.timezone=America/Argentina/Mendoza 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.45s J2 | TestMemoryPostingsFormat.testRandom <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=602, name=Thread-579, state=RUNNABLE, 
group=TGRP-TestMemoryPostingsFormat]
   [junit4]> 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 15962 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15962/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseParallelGC

22 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.TestTolerantSearch

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:50862/solr
at __randomizedtesting.SeedInfo.seed([FD712078342F498D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.TestTolerantSearch.createThings(TestTolerantSearch.java:75)
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:520)
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:804)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
at 

RE: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

[Uwe Schindler]

+1 to release!

I found a small thing that should be corrected in later versions:
Page 488: "Limitations: You must use an 'append-only' Lucene index codec 
because HDFS is an append-only filesystem. The currently
default codec used by Solr is 'append-only' and is supported with HDFS."

This is no longer correct, because you cannot write a codec anymore that is not 
append-only. Directory APIs only provide IndexOutputs on top of OutputStreams 
that are no longer are able to seek! So the whole "limitations" section is 
obsolete.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Chris Hostetter [mailto:hossman_luc...@fucit.org]
> Sent: Saturday, February 20, 2016 12:05 AM
> To: Lucene Dev 
> Cc: gene...@lucene.apache.org
> Subject: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf
> 
> 
> Please VOTE to release the following artifacts as
> apache-solr-ref-guide-5.5.pdf ...
> 
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-
> ref-guide-5.5-RC1/
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> 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-7039) Improve PointRangeQuery & co

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7039:


+1, lots of great changes here: removing {{ExactPointQuery}} to match how you 
make the range queries, awesome javadocs, factoring out argument checking, 
consolidating encode/decode in the same class, fixing {{toString}} to not be 
useless :)

Maybe we should rename {{PointRangeQuery}} to {{PointQuery}}?

I agree all the TODOs should be done separately.

Thanks [~rcmuir]!

> Improve PointRangeQuery & co
> 
>
> Key: LUCENE-7039
> URL: https://issues.apache.org/jira/browse/LUCENE-7039
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-7039.patch, LUCENE-7039.patch
>
>
> The point types are now preferred for indexing numeric fields, but 
> PointRangeQuery has some usability issues.
> I think we should make the following changes:
> * {{newIntRange()}}, {{newLongRange()}}, 
> {{newFloatRange()}},{{newDoubleRange()}}, {{newBinaryRange()}}: simple 1D 
> ranges consistent with NumericRangeQuery naming. 
> * {{newMultiIntRange()}}, {{newMultiLongRange()}}, {{newMultiFloatRange()}}, 
> {{newMultiDoubleRange()}}, {{newMultiBinaryRange()}}: multi-dimensional 
> versions of the above (take arrays, a bit harder to use, but the arrays have 
> correct type!)
> * {{toString()}} should be meaningful, it should not spew binary nonsense 
> unless you used a binary range!
> * improve javadocs
> If we like this, we could do similar improvements for the ExactPointQuery



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

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

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

[Anshum Gupta]

I think going forward, we should change the command to reflect the correct
tgz file name in the 'Installing Solr' section for the ref guide.

On Mon, Feb 22, 2016 at 10:54 AM, Anshum Gupta 
wrote:

> +1. Looks good to me.
>
> Thanks Hoss!
>
> On Fri, Feb 19, 2016 at 3:05 PM, Chris Hostetter  > wrote:
>
>>
>> Please VOTE to release the following artifacts as
>> apache-solr-ref-guide-5.5.pdf ...
>>
>>
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC1/
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>



-- 
Anshum Gupta

Re: VOTE: RC1 Release apache-solr-ref-guide-5.5.pdf

[Anshum Gupta]

+1. Looks good to me.

Thanks Hoss!

On Fri, Feb 19, 2016 at 3:05 PM, Chris Hostetter 
wrote:

>
> Please VOTE to release the following artifacts as
> apache-solr-ref-guide-5.5.pdf ...
>
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.5-RC1/
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Anshum Gupta

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8110:


I am sure there would be reasons for people to use field names that are 
outliers but we shouldn't really make our rule book for that. It would be good 
to
* start with a rather restricted set, that is universal across Solr in terms of 
identifier restrictions 
* relax them if there are valid use cases that require us to support more in 
future releases.
* make sure we maintain back-compat

It's easier to have restrictions to begin with and people could write client 
code that maps field names rather than work around in Solr for handling 
outliers.


> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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

[jira] [Commented] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8097:


Thanks Hoss. I'll work on adding support for this in SOLR-6312 without changing 
the default.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



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

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