[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+95) - Build # 14999 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14999/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseSerialGC 
-XX:-CompactStrings

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

Error Message:
Error from server at http://127.0.0.1:60002/awholynewcollection_0: Expected 
mime type application/octet-stream but got text/html.Error 
500HTTP ERROR: 500 Problem accessing 
/awholynewcollection_0/select. Reason: {msg=Error trying to proxy 
request for url: 
http://127.0.0.1:56996/awholynewcollection_0/select,trace=org.apache.solr.common.SolrException:
 Error trying to proxy request for url: 
http://127.0.0.1:56996/awholynewcollection_0/select  at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:591)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:441)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:110)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)  
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)  
at org.eclipse.jetty.server.Server.handle(Server.java:499)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)  at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
 at java.lang.Thread.run(Thread.java:747) Caused by: 
org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for 
connection from pool  at 
org.apache.http.impl.conn.PoolingClientConnectionManager.leaseConnection(PoolingClientConnectionManager.java:226)
  at 
org.apache.http.impl.conn.PoolingClientConnectionManager$1.getConnection(PoolingClientConnectionManager.java:195)
  at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:423)
  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.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:558)  
... 24 more ,code=500} Powered by 
Jetty://   

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


Error 500 


HTTP ERROR: 500
Problem accessing /awholynewcollection_0/select. Reason:
{msg=Error trying to proxy request for url: 
http://127.0.0.1:56996/awholynewcollection_0/select,trace=org.apache.solr.common.SolrException:
 Error trying to proxy request for url: 
http://127.0.0.1:56996/awholynewcollection_0/select
at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:591)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:441)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:223)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:110)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
  

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+95) - Build # 15297 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([7E5CB0D2EFB49D35:C48EDFAA6C9A7320]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:755)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:326)
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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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:747)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


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




Build Log:
[...truncated 9715 lines...]
   [junit4] Suite: 

[jira] [Commented] (LUCENE-6945) factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename TestParser to TestCoreParser

[ASF subversion and git services (JIRA)]

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

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

Commit 1721526 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1721526 ]

LUCENE-6945: rename TestParser to TestCoreParser

> factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename 
> TestParser to TestCoreParser
> --
>
> Key: LUCENE-6945
> URL: https://issues.apache.org/jira/browse/LUCENE-6945
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6945.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} or {{TestCorePlusQueriesParser}} or 
> {{TestCorePlusExtensionsParser}} depending on requirements.



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

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 890 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/890/

1 tests failed.
FAILED:  org.apache.lucene.search.TestGeoPointQuery.testRandomBig

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([BA52D210B88BBB04:3D05AF9F29D2C784]:0)
at org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:354)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:352)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:130)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:114)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:261)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:341)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:106)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:66)
at 
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4199)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4706)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:689)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4737)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4728)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1464)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1242)
at 
org.apache.lucene.util.BaseGeoPointTestCase.verify(BaseGeoPointTestCase.java:590)
at 
org.apache.lucene.util.BaseGeoPointTestCase.doTestRandom(BaseGeoPointTestCase.java:411)
at 
org.apache.lucene.util.BaseGeoPointTestCase.testRandomBig(BaseGeoPointTestCase.java:340)
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.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)




Build Log:
[...truncated 8281 lines...]
   [junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeoPointQuery 
-Dtests.method=testRandomBig -Dtests.seed=BA52D210B88BBB04 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/x1/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=mk -Dtests.timezone=Atlantic/Madeira -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   54.7s J0 | TestGeoPointQuery.testRandomBig <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([BA52D210B88BBB04:3D05AF9F29D2C784]:0)
   [junit4]>at 
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:354)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:352)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:130)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:114)
   [junit4]>at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:261)
   [junit4]>at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:341)
   [junit4]>at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:106)

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7339:
-

bq. I still think we probably have to roll this update back because it appears 
to break Solr under certain default Locales. We should probably try and isolate 
what is causing it so we can file a bug, but we would still need to wait for a 
good version.

Makes sense. I'll revert.

bq. Interesting exception in a CollectionsAPIDistributedZkTest fail:

I don't think that is caused by the jetty upgrade because it happens on 5x and 
5.4 branches too. I had opened SOLR-8380 to track it.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian 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-8455) Improve RecoveryStrategy logging and fix interval-between-recovery-attempts

[Shai Erera (JIRA)]

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

Shai Erera updated SOLR-8455:
-
Summary: Improve RecoveryStrategy logging and fix 
interval-between-recovery-attempts  (was: Minor improvements to 
RecoveryStrategy)

> Improve RecoveryStrategy logging and fix interval-between-recovery-attempts
> ---
>
> Key: SOLR-8455
> URL: https://issues.apache.org/jira/browse/SOLR-8455
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8455.patch, SOLR-8455.patch
>
>
> This issue addresses multiple minor improvements to {{RecoveryStrategy}}:
> * Logging improvements: proper use of Logger interface, improve log messages.
> * Consolidated a debug block into a method and reuse.
> * Get rid of unused and deprecated code.
> In addition, the code over-slept between recovery attempts. The inline 
> comment suggested that the intention was to sleep between 1 second to 1 
> minute, while implement an exponential sleep interval strategy. However in 
> practice the code sleeps in intervals of 5 seconds and up to 5 minutes. So I 
> fixed the code to sleep at interval of 5 seconds (checking if it was closed 
> in between sleep attempts) and up to 1 minute.



--
This message was sent by Atlassian 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-8455) Minor improvements to RecoveryStrategy

[ASF subversion and git services (JIRA)]

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

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

Commit 1721531 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1721531 ]

SOLR-8455: Improve RecoveryStrategy logging and fix 
interval-between-recovery-attempts

> Minor improvements to RecoveryStrategy
> --
>
> Key: SOLR-8455
> URL: https://issues.apache.org/jira/browse/SOLR-8455
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8455.patch, SOLR-8455.patch
>
>
> This issue addresses multiple minor improvements to {{RecoveryStrategy}}:
> * Logging improvements: proper use of Logger interface, improve log messages.
> * Consolidated a debug block into a method and reuse.
> * Get rid of unused and deprecated code.
> In addition, the code over-slept between recovery attempts. The inline 
> comment suggested that the intention was to sleep between 1 second to 1 
> minute, while implement an exponential sleep interval strategy. However in 
> practice the code sleeps in intervals of 5 seconds and up to 5 minutes. So I 
> fixed the code to sleep at interval of 5 seconds (checking if it was closed 
> in between sleep attempts) and up to 1 minute.



--
This message was sent by Atlassian 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-6945) factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename TestParser to TestCoreParser

[ASF subversion and git services (JIRA)]

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

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

Commit 1721543 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1721543 ]

LUCENE-6945: rename TestParser to TestCoreParser (merge in revision 1721526 
from trunk)

> factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename 
> TestParser to TestCoreParser
> --
>
> Key: LUCENE-6945
> URL: https://issues.apache.org/jira/browse/LUCENE-6945
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6945.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} or {{TestCorePlusQueriesParser}} or 
> {{TestCorePlusExtensionsParser}} depending on requirements.



--
This message was sent by Atlassian 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-8220) Read field from docValues for non stored fields

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8220:
---
Attachment: SOLR-8220.patch

Added tests for the previous two scenarios.
@Erick, thanks for the catch, the values.getValueCount() wasn't working indeed, 
and only after adding the test for it could I catch it.

Shalin, Erick, please review this latest patch. Thanks.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-5x.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
This message was sent by Atlassian 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-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8433:
-

bq. Uwe Schindler, is it possible that this test was not run on the latest 
trunk code?

This run used the SVN revision as noted in build description: Revision: 1721492 
(which is now 9 hours ago). So the repository was up-to-date.

> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
>[junit4]   2>  at 
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:480)
>[junit4]   2>  ... 11 more
>[junit4]   2> Caused by: sun.security.validator.ValidatorException: PKIX 
> path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>[junit4]   2>  at 
> sun.security.validator.Validator.validate(Validator.java:260)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
>[junit4]   2>  ... 29 more
>[junit4]   2> Caused by: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> 

[jira] [Created] (SOLR-8459) NPE using TermVectorComponent in combinition with ExactStatsCache

[Andreas Daffner (JIRA)]

Andreas Daffner created SOLR-8459:
-

 Summary: NPE using TermVectorComponent in combinition with 
ExactStatsCache
 Key: SOLR-8459
 URL: https://issues.apache.org/jira/browse/SOLR-8459
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3
Reporter: Andreas Daffner


Hello,

I am getting a NPE when using the TermVectorComponent in combinition with 
ExactStatsCache.
I am using SOLR 5.3.0 with 4 shards in total.

I set up my solrconfig.xml as described in these 2 links:
TermVectorComponent:
https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component

ExactStatsCache:
https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation


My snippets from solrconfig.xml:
{code}
...
  
  
  
  
  

  true


  tvComponent

  
...
{code}


Unfortunately a request to SOLR like 
"http://{host}/solr/{corename}/tvrh?q=site_url_id:74; ends up with this NPE:
{code}
4329458 ERROR (qtp59559151-17) [c:SingleDomainSite_11 s:shard1 r:core_node1 
x:SingleDomainSite_11_shard1_replica1] o.a.s.c.SolrCore 
java.lang.NullPointerException
at 
org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:454)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{code}

According to https://issues.apache.org/jira/browse/SOLR-7756 this Bug should be 
fixed with SOLR 5.3.0, but obviously this NPE is still present.
Can you please help me here?



--
This message was sent by Atlassian 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-6943) Jvm Crashes occassionaly with Lucene 4.6.1

[amit bhengra (JIRA)]

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

amit bhengra commented on LUCENE-6943:
--

Hi Michael,

We tried with NIOFSDirectory, we didn't get any jvm crash yet but we see there 
are heap issues now, this is probably due to file buffers being stored in heap 
now from my understanding and it is not getting completely collected during GC, 
any particular GC setting/solr cache setting you would suggest to resolve this ?

> Jvm Crashes occassionaly with Lucene 4.6.1
> --
>
> Key: LUCENE-6943
> URL: https://issues.apache.org/jira/browse/LUCENE-6943
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/query/scoring
>Affects Versions: 4.6.1
>Reporter: amit bhengra
> Attachments: hs_err_pid9889.log
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f5625212cd7, pid=9889, tid=139920130201344
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 
> 1.7.0_60-b19)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode 
> linux-amd64 )
> # Problematic frame:
> # J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126 
> bytes) @ 0x7f5625212cd7 [0x7f5625212c80+0x57]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core 
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.sun.com/bugreport/crash.jsp
> #
> Register to memory mapping:
> RAX=0x7f55de053510 is an oop
> {instance class} 
>  - klass: {other class}
> RBX=0x7f549dffc028 is an oop
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader 
>  - klass: 'org/apache/lucene/codecs/lucene41/Lucene41PostingsReader'
> RCX=0x0004 is an unknown value
> RDX=0x0080 is an unknown value
> RSP=0x7f41b1a7f640 is pointing into the stack for thread: 
> 0x7f48f81a4000
> RBP=0x7f4b1bff3630 is an oop
> java.nio.DirectByteBufferR 
>  - klass: 'java/nio/DirectByteBufferR'
> RSI=0x7f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput 
>  - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> RDI=0x237c532a is an unknown value
> R8 =0x237c4da3 is an unknown value
> R9 =0x7f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput 
>  - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> R10=0x7f3a8f98a000 is an unknown value
> R11=0x237c4da3 is an unknown value
> R12=0x7f41b1a81f30 is pointing into the stack for thread: 
> 0x7f48f81a4000
> R13=0x0093 is an unknown value
> R14=0x431f is an unknown value
> R15=0x7f48f81a4000 is a thread
> Stack: [0x7f41b1985000,0x7f41b1a86000],  sp=0x7f41b1a7f640,  free 
> space=1001k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126 
> bytes) @ 0x7f5625212cd7 [0x7f5625212c80+0x57]
> J 4940 C2 
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextPosition()I
>  (118 bytes) @ 0x7f5624515cb4 [0x7f5624515980+0x334]
> J 10578 C2 org.apache.lucene.search.ExactPhraseScorer.phraseFreq()I (624 
> bytes) @ 0x7f56256de588 [0x7f56256de4e0+0xa8]
> J 10629 C2 org.apache.lucene.search.ExactPhraseScorer.advance(I)I (152 bytes) 
> @ 0x7f5625729d84 [0x7f5625729ba0+0x1e4]
> J 10433 C2 org.apache.lucene.search.MinShouldMatchSumScorer.advance(I)I (113 
> bytes) @ 0x7f5625653c34 [0x7f5625653ae0+0x154]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @ 
> 0x7f5624642a10 [0x7f5624642820+0x1f0]
> J 5826 C2 org.apache.lucene.search.DisjunctionScorer.advance(I)I (87 bytes) @ 
> 0x7f56246f140c [0x7f56246f13c0+0x4c]
> J 8801 C2 
> org.apache.lucene.search.join.FkToChildBlockJoinQuery$FkToChildBlockJoinScorer.advance(I)I
>  (284 bytes) @ 0x7f56251274c0 [0x7f5625127440+0x80]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @ 
> 0x7f56246429fc [0x7f5624642820+0x1dc]
> J 4797 C2 
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.score(Lorg/apache/lucene/search/Collector;)V
>  (91 bytes) @ 0x7f56244e9ccc [0x7f56244e9c40+0x8c]
> J 4613 C2 
> org.apache.lucene.search.IndexSearcher.search(Ljava/util/List;Lorg/apache/lucene/search/Weight;Lorg/apache/lucene/search/Collector;)V
>  (93 bytes) @ 0x7f562446cbec [0x7f562446ca80+0x16c]
> J 6159 C2 
> 

[jira] [Comment Edited] (SOLR-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8433 at 12/23/15 3:54 PM:
---

bq. Uwe Schindler, is it possible that this test was not run on the latest 
trunk code?

This run used the SVN revision as noted in build description: Revision: 1721492 
(which is now 9 hours ago). So the repository was up-to-date.

According to the workspace it also has the log line: 


{code:java}
  static {
ModifiableSolrParams params = new ModifiableSolrParams();
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS, 128);
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST, 32);
HttpClientConfigurer configurer = HttpClientUtil.getConfigurer();
log.info("### HttpClientConfigurer 
##:"+configurer.getClass());
httpClient =  HttpClientUtil.createClient(params);
  }
{code:java}

You might not have seen the log line, because the {{static}} block was 
triggered already by an earlier test running (the class is initialized by the 
first test that implcitely uses the IterativeMergeStrategy! 


was (Author: thetaphi):
bq. Uwe Schindler, is it possible that this test was not run on the latest 
trunk code?

This run used the SVN revision as noted in build description: Revision: 1721492 
(which is now 9 hours ago). So the repository was up-to-date.

> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
>[junit4]   2>  at 
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:480)
>[junit4]   2>  ... 11 more
>[junit4]   2> Caused by: 

[jira] [Comment Edited] (SOLR-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8433 at 12/23/15 3:54 PM:
---

bq. Uwe Schindler, is it possible that this test was not run on the latest 
trunk code?

This run used the SVN revision as noted in build description: Revision: 1721492 
(which is now 9 hours ago). So the repository was up-to-date.

According to the workspace it also has the log line: 


{code:java}
  static {
ModifiableSolrParams params = new ModifiableSolrParams();
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS, 128);
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST, 32);
HttpClientConfigurer configurer = HttpClientUtil.getConfigurer();
log.info("### HttpClientConfigurer 
##:"+configurer.getClass());
httpClient =  HttpClientUtil.createClient(params);
  }
{code}

You might not have seen the log line, because the {{static}} block was 
triggered already by an earlier test running (the class is initialized by the 
first test that implcitely uses the IterativeMergeStrategy! 


was (Author: thetaphi):
bq. Uwe Schindler, is it possible that this test was not run on the latest 
trunk code?

This run used the SVN revision as noted in build description: Revision: 1721492 
(which is now 9 hours ago). So the repository was up-to-date.

According to the workspace it also has the log line: 


{code:java}
  static {
ModifiableSolrParams params = new ModifiableSolrParams();
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS, 128);
params.set(HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST, 32);
HttpClientConfigurer configurer = HttpClientUtil.getConfigurer();
log.info("### HttpClientConfigurer 
##:"+configurer.getClass());
httpClient =  HttpClientUtil.createClient(params);
  }
{code:java}

You might not have seen the log line, because the {{static}} block was 
triggered already by an earlier test running (the class is initialized by the 
first test that implcitely uses the IterativeMergeStrategy! 

> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> 

[jira] [Commented] (SOLR-8460) /analysis/field doesn't always handle custom attributes correctly

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8460:
-

Can you provide an example TokenStream, For me it always works. The whole thing 
is buggy, I agree, but it should work with TokenStreams.

The most important thing: You have to implement the {{reflectWith()}} 
functionality correctly.

bq. Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
wouldn't find an attribute added by the input TokenStream.

Thats a bug in your TokenStream! getAttribute is only available for TokenStream 
consumers that don't want to add attributes they don't need. Producer code must 
always use addAttribute().

bq. Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
trigger an exception.

If you use an AttributeFactory it should work correctly. In any case we should 
check that the ListBasedTokenStream uses the same attribute factory as the 
original tokenstream. This could be the bug here. Because it needs to clone the 
atttibutes and this fails if the original and the ListBasedTokenSteam uses 
different factories.

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8451) We should not call method.abort in HttpSolrClient.

[Karl Wright (JIRA)]

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

Karl Wright commented on SOLR-8451:
---

I don't follow the reasoning here.  AFAICT method.abort should be called 
whenever there's any chance that the response has not been fully read, which 
would be the case if an exception was thrown.


> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8451.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] [Created] (SOLR-8460) /analysis/field doesn't always handle custom attributes correctly

[David Smiley (JIRA)]

David Smiley created SOLR-8460:
--

 Summary: /analysis/field doesn't always handle custom attributes 
correctly
 Key: SOLR-8460
 URL: https://issues.apache.org/jira/browse/SOLR-8460
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
 Fix For: 5.5


I've got some custom analysis Attribute implementations in my analysis chain 
with some other custom analysis components.  I found that Solr's Analysis 
utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
* Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
trigger an exception.
* Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8459) NPE using TermVectorComponent in combinition with ExactStatsCache

[Andreas Daffner (JIRA)]

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

Andreas Daffner updated SOLR-8459:
--
Description: 
Hello,

I am getting a NPE when using the TermVectorComponent in combinition with 
ExactStatsCache.
I am using SOLR 5.3.0 with 4 shards in total.

I set up my solrconfig.xml as described in these 2 links:
TermVectorComponent:
https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component

ExactStatsCache:
https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation


My snippets from solrconfig.xml:
{code}
...
  
  
  
  
  

  true


  tvComponent

  
...
{code}


Unfortunately a request to SOLR like 
"http://host/solr/corename/tvrh?q=site_url_id:74; ends up with this NPE:
{code}
4329458 ERROR (qtp59559151-17) [c:SingleDomainSite_11 s:shard1 r:core_node1 
x:SingleDomainSite_11_shard1_replica1] o.a.s.c.SolrCore 
java.lang.NullPointerException
at 
org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:454)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{code}

According to https://issues.apache.org/jira/browse/SOLR-7756 this Bug should be 
fixed with SOLR 5.3.0, but obviously this NPE is still present.
Can you please help me here?

  was:
Hello,

I am getting a NPE when using the TermVectorComponent in combinition with 
ExactStatsCache.
I am using SOLR 5.3.0 with 4 shards in total.

I set up my solrconfig.xml as described in these 2 links:
TermVectorComponent:
https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component

ExactStatsCache:
https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation


My snippets from solrconfig.xml:
{code}
...
  
  
  
  
  

  true


  tvComponent

  
...
{code}


Unfortunately a request to SOLR like 
"http://{host}/solr/{corename}/tvrh?q=site_url_id:74; ends up with this NPE:
{code}
4329458 ERROR (qtp59559151-17) [c:SingleDomainSite_11 s:shard1 r:core_node1 
x:SingleDomainSite_11_shard1_replica1] o.a.s.c.SolrCore 
java.lang.NullPointerException
at 
org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:454)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at 

[jira] [Updated] (SOLR-8451) We should not call method.abort in HttpSolrClient.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8451:
--
Summary: We should not call method.abort in HttpSolrClient.  (was: We 
should be calling method.abort before response.close in HttpSolrClient)

> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>




--
This message was sent by Atlassian 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-8451) We should not call method.abort in HttpSolrClient.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8451:
---

bq. whenever there's any chance that the response has not been fully read

No documentation I can find says that.

If you make a little test, you will see that method.abort prevents connection 
reuse. When Solr throws expected errors for updates, we don't want to poison 
the connection, we want it to go back to the pool. If we actually had to read 
the full stream, it would be better to just do that. But again, testing and any 
documentation I can find shows that we just have to close the stream - we don't 
have to read it all. And connections are released happily back to the pool for 
reuse.

There is no need for abort here. Nor was it even having an affect when it was 
called after the content stream close (which it always was).

> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8451.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-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8433:
--

This test failure doesn't seem to be running the latest code: 
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/277/consoleText

In the most recent IterativeMergeStrategy the HttpClientConfigurer is logged:

https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/component/IterativeMergeStrategy.java
log.info("### HttpClientConfigurer 
##:"+configurer.getClass());

This output is not appearing in the test output but appears on local test runs.

[~thetaphi], is it possible that this test was not run on the latest trunk code?


> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
>[junit4]   2>  at 
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:480)
>[junit4]   2>  ... 11 more
>[junit4]   2> Caused by: sun.security.validator.ValidatorException: PKIX 
> path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>[junit4]   2>  at 
> sun.security.validator.Validator.validate(Validator.java:260)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>[junit4]   2>  at 
> 

[jira] [Commented] (SOLR-8460) /analysis/field doesn't always handle custom attributes correctly

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8460:
-

That was exactly the issue I had in mind :-) Thanks for fixing! In any case, 
the whole thing is a huge bug and should be rewritten!

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



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

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_66) - Build # 15288 - Failure!

[Steve Rowe]

Another reproducible failure from my Jenkins:

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestDimensionalRangeQuery 
-Dtests.method=testAllDimensionalDocsWereDeletedAndThenMergedAgain 
-Dtests.seed=B398F471D8C24FB2 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=zh_SG -Dtests.timezone=Asia/Damascus -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.22s | 
TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain 
<<<
   [junit4]> Throwable #1: java.lang.IllegalStateException: must index at 
least one point
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B398F471D8C24FB2:5CE55CC1B5D7B2F]:0)
   [junit4]>at 
org.apache.lucene.util.bkd.BKDWriter.finish(BKDWriter.java:742)
   [junit4]>at 
org.apache.lucene.codecs.simpletext.SimpleTextDimensionalWriter.writeField(SimpleTextDimensionalWriter.java:160)
   [junit4]>at 
org.apache.lucene.codecs.DimensionalWriter.mergeOneField(DimensionalWriter.java:44)
   [junit4]>at 
org.apache.lucene.codecs.DimensionalWriter.merge(DimensionalWriter.java:106)
   [junit4]>at 
org.apache.lucene.index.SegmentMerger.mergeDimensionalValues(SegmentMerger.java:168)
   [junit4]>at 
org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:117)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4062)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
   [junit4]>at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
   [junit4]>at 
org.apache.lucene.search.TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain(TestDimensionalRangeQuery.java:1003)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> NOTE: test params are: codec=SimpleText, 
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, locale=zh_SG, 
timezone=Asia/Damascus
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_45 (64-bit)/cpus=16,threads=1,free=426065104,total=514850816
   [junit4]   2> NOTE: All tests run in this JVM: [TestDimensionalRangeQuery]
   [junit4] Completed [1/1 (1!)] in 0.41s, 1 test, 1 error <<< FAILURES!



> On Dec 22, 2015, at 2:36 PM, Michael McCandless  
> wrote:
> 
> I'll dig
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> 
> On Tue, Dec 22, 2015 at 11:40 AM, Policeman Jenkins Server
>  wrote:
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15288/
>> Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseSerialGC
>> 
>> 1 tests failed.
>> FAILED:  
>> org.apache.lucene.search.TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain
>> 
>> Error Message:
>> must index at least one point
>> 
>> Stack Trace:
>> java.lang.IllegalStateException: must index at least one point
>>at 
>> __randomizedtesting.SeedInfo.seed([AAC8CFA944E142D1:1C9E6E14877E764C]:0)
>>at org.apache.lucene.util.bkd.BKDWriter.finish(BKDWriter.java:742)
>>at 
>> org.apache.lucene.codecs.simpletext.SimpleTextDimensionalWriter.writeField(SimpleTextDimensionalWriter.java:160)
>>at 
>> org.apache.lucene.codecs.DimensionalWriter.mergeOneField(DimensionalWriter.java:44)
>>at 
>> org.apache.lucene.codecs.DimensionalWriter.merge(DimensionalWriter.java:106)
>>at 
>> org.apache.lucene.index.SegmentMerger.mergeDimensionalValues(SegmentMerger.java:168)
>>at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:117)
>>at 
>> org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4062)
>>at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
>>at 
>> org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
>>at 
>> org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
>>at 
>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
>>at 
>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
>>at 
>> org.apache.lucene.search.TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain(TestDimensionalRangeQuery.java:1003)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>at 
>> 

[jira] [Updated] (SOLR-8451) We should not call method.abort in HttpSolrClient.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8451:
--
Attachment: SOLR-8451.patch

> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
> Attachments: SOLR-8451.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-8451) We should not call method.abort in HttpSolrClient.

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-8451:
-

Assignee: Mark Miller

> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8451.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

Re: 5.3.2 bug fix release

[Anshum Gupta]

I've added the section for 5.3.2 in all the branches. Kindly back-port
stuff that you think makes sense to go into a 'bug-fix' release for 5.3.1
only.

I think it'd make sense to duplicate entries for JIRAs we back port.

On Mon, Dec 21, 2015 at 11:38 AM, Anshum Gupta 
wrote:

> Seems like Noble ran addVersion.py for 5.3.2 on the lucene_solr_5_3 branch
> during the 5.3.1 release.
> I can now run it for branch_5x and trunk with the old change id but there
> are a ton of property changes to multiple files. Can someone confirm that
> it'd be fine? The addVersion on 5.3.2, that I'm trying to merge onto
> branch_5x and trunk was done before 5.4 was released.
>
> Also, the change log entry for 5.3.2 is right above 5.3.1 and not
> chronological i.e. at the top. I think that is how it should be unless
> someone has some different ideas.
>
> On Thu, Dec 17, 2015 at 2:42 AM, Shawn Heisey  wrote:
>
>> On 12/16/2015 1:08 PM, Anshum Gupta wrote:
>> > There are a bunch of important bug fixes that call for a 5.3.2 in my
>> > opinion. I'm specifically talking about security plugins related fixes
>> > but I'm sure there are others too.
>> >
>> > Unless someone else wants to do it, I'd volunteer to do the release
>> > and cut an RC next Tuesday.
>>
>> Sounds like a reasonable idea to me.  I assume these must be fixes that
>> are not yet backported.
>>
>> I happen to have the 5.3 branch on my dev system, with SOLR-6188
>> applied.  It is already up to date.  There's nothing in the 5.3.2
>> section of either CHANGES.txt file.  The svn log indicates that nothing
>> has been backported since the 5.3.1 release was cut.
>>
>> Perhaps SOLR-6188 could be added to the list of fixes to backport.  I
>> believe it's a benign change.
>>
>> Thinking about CHANGES.txt, this might work for the 5.3 branch:
>>
>> 
>> === Lucene 5.3.2 ===
>> All changes were backported from 5.4.0.
>>
>> Bug Fixes
>>
>> * LUCENE-: A description (Committer Name)
>> 
>>
>> If we decide it's a good idea to mention the release in trunk and
>> branch_5x, something like the following might work, because that file
>> should already contain the full change descriptions:
>>
>> 
>> === Lucene 5.3.2 ===
>> The following issues were backported from 5.4.0:
>> LUCENE-
>> LUCENE-
>> 
>>
>> Thanks,
>> Shawn
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Anshum Gupta
>



-- 
Anshum Gupta

[jira] [Comment Edited] (SOLR-8460) /analysis/field doesn't always handle custom attributes correctly

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8460 at 12/23/15 4:08 PM:
---

Can you provide an example TokenStream, For me it always works. The whole thing 
is buggy, I agree, but it should work with correctly implemented TokenStreams.

The most important thing: You have to implement the {{reflectWith()}} 
functionality correctly.

bq. Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
wouldn't find an attribute added by the input TokenStream.

Thats a bug in your TokenStream! getAttribute is only available for TokenStream 
consumers that don't want to add attributes they don't need. Producer code must 
always use addAttribute().

bq. Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
trigger an exception.

If you use an AttributeFactory it should work correctly. In any case we should 
check that the ListBasedTokenStream uses the same attribute factory as the 
original tokenstream. This could be the bug here. Because it needs to clone the 
atttibutes and this fails if the original and the ListBasedTokenSteam uses 
different factories.


was (Author: thetaphi):
Can you provide an example TokenStream, For me it always works. The whole thing 
is buggy, I agree, but it should work with TokenStreams.

The most important thing: You have to implement the {{reflectWith()}} 
functionality correctly.

bq. Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
wouldn't find an attribute added by the input TokenStream.

Thats a bug in your TokenStream! getAttribute is only available for TokenStream 
consumers that don't want to add attributes they don't need. Producer code must 
always use addAttribute().

bq. Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
trigger an exception.

If you use an AttributeFactory it should work correctly. In any case we should 
check that the ListBasedTokenStream uses the same attribute factory as the 
original tokenstream. This could be the bug here. Because it needs to clone the 
atttibutes and this fails if the original and the ListBasedTokenSteam uses 
different factories.

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8460) /analysis/field doesn't always handle custom attributes correctly

[David Smiley (JIRA)]

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

David Smiley updated SOLR-8460:
---
Attachment: SOLR_8460.patch

See attached patch.

This fix is for ARHB.ListBasedTokenStream to take an AttributeSource in the 
constructor to serve as the source of the attribute impls which are added in 
the constructor in a loop.  This adds the attributes as side effect as well. 
There is then no reason to copy the defined attributes in incrementToken 
because it's done in the constructor.

I'll commit in a couple days pending feedback.

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8451) We should not call method.abort in HttpSolrClient.

[Karl Wright (JIRA)]

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

Karl Wright commented on SOLR-8451:
---

Hmm, under some circumstances this is definitely not the right thing to do.  
http://stackoverflow.com/questions/1565349/cancel-abort-a-connection-from-the-threadsafeclientconnmanager-connection-pool


> We should not call method.abort in HttpSolrClient.
> --
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8451.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-8451) We should be calling method.abort before response.close in HttpSolrClient

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8451:
---

Okay, I dug into this a bit. Actually, we should not call abort at all. Right 
now, since we call it after close, it's harmless though.

Also, ConcurrentUpdateSolrClient very oddly seem to always not read that last 
40 or 44 bytes of the server response even on successful requests. That's odd, 
but should not mess with connection reuse. We only have to ensure we close the 
content stream, not read it all.

> We should be calling method.abort before response.close in HttpSolrClient
> -
>
> Key: SOLR-8451
> URL: https://issues.apache.org/jira/browse/SOLR-8451
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>




--
This message was sent by Atlassian 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-6945) factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename TestParser to TestCoreParser

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6945.
-
Resolution: Fixed

> factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename 
> TestParser to TestCoreParser
> --
>
> Key: LUCENE-6945
> URL: https://issues.apache.org/jira/browse/LUCENE-6945
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6945.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} or {{TestCorePlusQueriesParser}} or 
> {{TestCorePlusExtensionsParser}} depending on requirements.



--
This message was sent by Atlassian 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-8452) replace "partialResults" occurrences with SolrQueryResponse.RESPONSE_HEADER_PARTIAL_RESULTS_KEY

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8452.
---
   Resolution: Fixed
Fix Version/s: Trunk
   5.5

> replace "partialResults" occurrences with 
> SolrQueryResponse.RESPONSE_HEADER_PARTIAL_RESULTS_KEY
> ---
>
> Key: SOLR-8452
> URL: https://issues.apache.org/jira/browse/SOLR-8452
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8452.patch
>
>
> proposed patch against trunk to follow (The 
> {{TestSolrQueryResponse.testResponseHeaderPartialResults()}} test within the 
> patch is to ensure that inadvertent, non-backwards-compatible changes to 
> {{SolrQueryResponse.RESPONSE_HEADER_PARTIAL_RESULTS_KEY}} result in test 
> failure.)



--
This message was sent by Atlassian 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-8415) Provide command to switch between non/secure mode in ZK

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-8415:
--

{quote}It's pretty straightforward to do this with access to writing some java 
classes, but at that point I'm not sure who our audience is.{quote}

The point was the proposed documentation was incorrect.  Our audience is 
someone who wants to switch from one secure acl regime to another.  If you 
don't think that's a popular enough use case to warrant documentation then I'd 
suggest getting rid of that part including the incorrect information.

> Provide command to switch between non/secure mode in ZK
> ---
>
> Key: SOLR-8415
> URL: https://issues.apache.org/jira/browse/SOLR-8415
> Project: Solr
>  Issue Type: Improvement
>  Components: security, SolrCloud
>Reporter: Mike Drob
>Assignee: Gregory Chanan
> Fix For: Trunk
>
> Attachments: SOLR-8415.patch, SOLR-8415.patch
>
>
> We have the ability to run both with and without zk acls, but we don't have a 
> great way to switch between the two modes. Most common use case, I imagine, 
> would be upgrading from an old version that did not support this to a new 
> version that does, and wanting to protect all of the existing content in ZK, 
> but it is conceivable that a user might want to remove ACLs as well.



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

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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7887:


Sure, we can give async a try.  I have seen this, so it was already on my radar:

http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
This message was sent by Atlassian 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-8462) /stream handler should return something when exception has no message

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-8462:
--
Summary: /stream handler should return something when exception has no 
message  (was: /stream handler failures should return more information when 
exception message missing.)

> /stream handler should return something when exception has no message
> -
>
> Key: SOLR-8462
> URL: https://issues.apache.org/jira/browse/SOLR-8462
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Priority: Trivial
> Fix For: Trunk
>
>
> Currently, the /stream request handler reports errors by adding an 
> "EXCEPTION" name/value pair on a tuple in the TupleStream where the error 
> arose.  The "value" in this name/value pair is the message attached to the 
> exception.
> This works well in most instances, however not all exceptions have messages.  
> {{NullPointerExceptions}} and other run time exceptions are often in this 
> group.  This causes the /stream handler to return the relatively unhelpful 
> value: {"EXCEPTION":null,"EOF":true}
> The purpose of this JIRA is to change error handling in the /stream handler, 
> so that more helpful information is returned when the handled exception has 
> no message.
> This information could simply be the name of the exception that was received. 
>  Or it could be something more involved.  Not sure what would be the most 
> helpful here.



--
This message was sent by Atlassian 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-8439) Solr Security - Permission read does not work as expected

[Gaurav Kumar (JIRA)]

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

Gaurav Kumar commented on SOLR-8439:


Is it possible to backport it to 5.3.1? We were trying to upgrade to 5.3.1 to 
get the new security features, please recommend a recommended version based on 
bug fixes related to security fixes.

> Solr Security - Permission read does not work as expected
> -
>
> Key: SOLR-8439
> URL: https://issues.apache.org/jira/browse/SOLR-8439
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3.1
> Environment: Linux, Solr Cloud
>Reporter: Gaurav Kumar
>Priority: Critical
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> I enabled security on my solr cloud and added basic authentication and 
> authorization to allow only specific users to read and update the records. 
> What I observed that update works fine but read does not stop from anonymous 
> access. 
> On digging deeper I saw that RuleBasedAuthorizationPlugin.java has 
> incorrectly defined the read permissions as follows:
> read :{" +
>   "  path:['/update/*', '/get']}," +
> It should be /select/* rather than /update/*



--
This message was sent by Atlassian 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-8461) CloudSolrStream and ParallelStream can choose replicas that are not active

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8461:


 Summary: CloudSolrStream and ParallelStream can choose replicas 
that are not active
 Key: SOLR-8461
 URL: https://issues.apache.org/jira/browse/SOLR-8461
 Project: Solr
  Issue Type: Bug
Reporter: Joel Bernstein


Currently CloudSolrStream and ParallelStream don't check the state of the 
replicas they route requests to. This can result in replicas that are not 
active receiving request.



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

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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7887:


If anyone has a complete LogWatcher implementation for logback, I'd also like 
to add that to Solr, so users would have another option without a ton of work.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
This message was sent by Atlassian 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-trunk-Linux (32bit/jdk1.8.0_66) - Build # 15300 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15300/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([C351BAD688544EF5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:229)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
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$7.evaluate(RandomizedRunner.java:834)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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 9945 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_C351BAD688544EF5-001/init-core-data-001
   [junit4]   2> 271825 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.a.s.SolrTestCaseJ4 ###Starting doTestStressReplication
   [junit4]   2> 271825 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_C351BAD688544EF5-001/solr-instance-001/collection1
   [junit4]   2> 271828 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.e.j.s.Server jetty-9.3.6.v20151106
   [junit4]   2> 271829 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@d52fd4{/solr,null,AVAILABLE}
   [junit4]   2> 271831 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.e.j.s.ServerConnector Started 
ServerConnector@96b37f{HTTP/1.1,[http/1.1]}{127.0.0.1:51800}
   [junit4]   2> 271831 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.e.j.s.Server Started @273545ms
   [junit4]   2> 271831 INFO  
(TEST-TestReplicationHandler.doTestStressReplication-seed#[C351BAD688544EF5]) [ 
   ] o.a.s.c.s.e.JettySolrRunner Jetty properties: 
{solr.data.dir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_C351BAD688544EF5-001/solr-instance-001/collection1/data,
 hostContext=/solr, hostPort=51800}
   [junit4]   2> 271831 INFO  

[jira] [Created] (SOLR-8463) FacetComponent throw NPE when using shards.tolerant and a shard fails to respond

[Ran Peled (JIRA)]

Ran Peled created SOLR-8463:
---

 Summary: FacetComponent throw NPE when using shards.tolerant and a 
shard fails to respond
 Key: SOLR-8463
 URL: https://issues.apache.org/jira/browse/SOLR-8463
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.3.1
 Environment: Distributed Search
Reporter: Ran Peled


When using shards.tolerant distributed search, and some shards fail to respond, 
FacetComponent.handleResponses() throws NPE.

This is similar to SOLR-1665: add distributed support, fixed in 4.10.



--
This message was sent by Atlassian 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-5209) last replica removal cascades to remove shard from clusterstate

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-5209:
---

[~markrmil...@gmail.com] - if you have no objections then I will re-assign this 
ticket to myself with a view towards committing it in the first half of January 
or so, to trunk (and not branch_5x) in good time for the 6.0.0 release 
hopefully, after reviews of course.

Everyone - the latest {{SOLR-5209.patch}} attachment contains the (small) 
change itself, a new {{OverseerTest.testRemovalOfLastReplica()}} test plus 
adjustments to existing tests. Reviews, comments, suggestions etc. welcome. 
Thank you.

> last replica removal cascades to remove shard from clusterstate
> ---
>
> Key: SOLR-5209
> URL: https://issues.apache.org/jira/browse/SOLR-5209
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Mark Miller
>Priority: Blocker
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-5209.patch, SOLR-5209.patch
>
>
> The problem we saw was that unloading of an only replica of a shard deleted 
> that shard's info from the clusterstate. Once it was gone then there was no 
> easy way to re-create the shard (other than dropping and re-creating the 
> whole collection's state).
> This seems like a bug?
> Overseer.java around line 600 has a comment and commented out code:
> // TODO TODO TODO!!! if there are no replicas left for the slice, and the 
> slice has no hash range, remove it
> // if (newReplicas.size() == 0 && slice.getRange() == null) {
> // if there are no replicas left for the slice remove it



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

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

[jira] [Updated] (SOLR-8463) FacetComponent throw NPE when using shards.tolerant and a shard fails to respond

[Ran Peled (JIRA)]

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

Ran Peled updated SOLR-8463:

Attachment: SOLR-8463.patch

> FacetComponent throw NPE when using shards.tolerant and a shard fails to 
> respond
> 
>
> Key: SOLR-8463
> URL: https://issues.apache.org/jira/browse/SOLR-8463
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3.1
> Environment: Distributed Search
>Reporter: Ran Peled
> Attachments: SOLR-8463.patch
>
>
> When using shards.tolerant distributed search, and some shards fail to 
> respond, FacetComponent.handleResponses() throws NPE.
> This is similar to SOLR-1665: add distributed support, fixed in 4.10.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/15002/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([5A9BE9958776716F:C06F947719ECED53]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:749)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:244)
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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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:747)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


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




Build Log:
[...truncated 10756 lines...]
   [junit4] Suite: 

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Pushkar Raste (JIRA)]

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

Pushkar Raste commented on SOLR-7887:
-

@[~elyograg] Current log4j 1.x config doesn't use async appenders which could 
be a performance bottleneck, if I you going to put together log4j2 
configuration please consider using Async appenders. I know the down side of it 
is if application crashes you will lose some logs but disk I/O for logs would 
be greatly reduced if we use Async Appenders 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
This message was sent by Atlassian 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-8460) /analysis/field doesn't always handle custom attributes correctly

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-8460:


Thanks for your review Uwe!  It's good to get more eyes on each others work.  
Looks like our first comments were written simultaneously without the benefit 
of each of us seeing what the other were about to say.

bq. Thats a bug in your TokenStream! getAttribute is only available for 
TokenStream consumers that don't want to add attributes they don't need. 
Producer code must always use addAttribute().

I wrote an Attribute implementation in such a way that it didn't _require_ some 
other attribute, but if it was present then it affected the functionality of 
the Attribute.  So to know if it's present or not, I called getAttribute.

Do you think the patch is fine as is to be committed or do you have 
concerns/feedback?

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8460) /analysis/field doesn't always handle custom attributes correctly

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8460:
-

I have no real concerns. The only thing I don't really like is the use of 
addAttributeImpl() in the test. This method is @Internal and should not really 
be used. It was made public for some special cases like TeeSinkTokenFilter. 
Maybe we can hide it now. The correct way to make the attribute API use a 
custom attribute impl is to provide an AttributeFactory that returns the custom 
implementation for the interface.

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8415) Provide command to switch between non/secure mode in ZK

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8415:
-

bq. Let's say you wanted to switch from secure setup old: (old acls, old 
credentials) to secure setup new (new acls, new credentials). You can call 
resetacls with (old acls + new acls, old credentials). Then call reset acls 
with (new acls, new credentials). That requires an intermediate step, but it 
isn't unsecure

I continued working on this and the main "problem" is that 
{{VMParamsAllAndReadonlyDigestZkACLProvider}} and 
{{VMParamsSingleSetCredentialsDigestZkCredentialsProvider}} use the same VM 
properties for the ACLs and Credentials. Normally, this is nice and makes 
things simpler, but when migrating and you want them to be different then that 
doesn't help us much. Since those are the only two out of the box Providers, 
the unsecure route is the only option when using the command line only.

It's pretty straightforward to do this with access to writing some java 
classes, but at that point I'm not sure who our audience is.

> Provide command to switch between non/secure mode in ZK
> ---
>
> Key: SOLR-8415
> URL: https://issues.apache.org/jira/browse/SOLR-8415
> Project: Solr
>  Issue Type: Improvement
>  Components: security, SolrCloud
>Reporter: Mike Drob
>Assignee: Gregory Chanan
> Fix For: Trunk
>
> Attachments: SOLR-8415.patch, SOLR-8415.patch
>
>
> We have the ability to run both with and without zk acls, but we don't have a 
> great way to switch between the two modes. Most common use case, I imagine, 
> would be upgrading from an old version that did not support this to a new 
> version that does, and wanting to protect all of the existing content in ZK, 
> but it is conceivable that a user might want to remove ACLs as well.



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

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

[jira] [Commented] (SOLR-8248) Log a query as soon as it comes in and assign a unique id to it

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8248:


SOLR-7887 is the issue to upgrade log4j.  Feel free to join in there.

> Log a query as soon as it comes in and assign a unique id to it
> ---
>
> Key: SOLR-8248
> URL: https://issues.apache.org/jira/browse/SOLR-8248
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Pushkar Raste
>Priority: Minor
>
> Often times when there is an OutOfMemory error Solr fails to log details 
> about query that might have caused it. Solr doesn't provide enough 
> information to investigate the root cause in such case. 
> We can log a query as soon as it comes in and reference it by it's unique id 
> to log details like Hits, Status and QTime  when query finishes. 



--
This message was sent by Atlassian 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-8462) /stream handler failures should return more information when exception message missing.

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-8462:
-

 Summary: /stream handler failures should return more information 
when exception message missing.
 Key: SOLR-8462
 URL: https://issues.apache.org/jira/browse/SOLR-8462
 Project: Solr
  Issue Type: Improvement
Affects Versions: Trunk
Reporter: Jason Gerlowski
Priority: Trivial
 Fix For: Trunk


Currently, the /stream request handler reports errors by adding an "EXCEPTION" 
name/value pair on a tuple in the TupleStream where the error arose.  The 
"value" in this name/value pair is the message attached to the exception.

This works well in most instances, however not all exceptions have messages.  
{{NullPointerExceptions}} and other run time exceptions are often in this 
group.  This causes the /stream handler to return the relatively unhelpful 
value: {"EXCEPTION":null,"EOF":true}

The purpose of this JIRA is to change error handling in the /stream handler, so 
that more helpful information is returned when the handled exception has no 
message.

This information could simply be the name of the exception that was received.  
Or it could be something more involved.  Not sure what would be the most 
helpful here.



--
This message was sent by Atlassian 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-8220) Read field from docValues for non stored fields

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8220:


bq. does the DocValues.getDocsWithField allocate a BitSet or just return a 
pre-existing instance
While I tried to track it down, I thought it is backed by a pre-existing bitset 
instance, as created at the leaf reader level. I didn't think it was a 
performance concern. Could someone confirm this understanding, please? 
Moreover, since Yonik suggested its use, I was more confident about using it.

> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-5x.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
This message was sent by Atlassian 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-8460) /analysis/field doesn't always handle custom attributes correctly

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8460:
-

bq. I wrote an Attribute implementation in such a way that it didn't require 
some other attribute, but if it was present then it affected the functionality 
of the Attribute. So to know if it's present or not, I called getAttribute.

That's fine. It was just general comment: If your TokenFilter needs a specific 
attribute, it should call addAttribute. If it only optionally uses it when 
available, a check with hasAttribute() is fine, too. Although I cannot 
guarantee that this works with all consumers (like this one!). Some producers 
make attributes available in a delayed way (e.g. on reset()), so calling 
hasAttribute or getAttribute on ctor may not reflect the real state. I think 
this is what happened here (because attribute init was delayed to 
incrementToken). I don't know why this was implemented like that - maybe 
because of the delayed attrbutes.

I'd suggest to still crosscheck in incrementToken() if all Attributes are 
ready. It is not a performance issue for this handler, as it is intended for 
debugging only. So I would leave incrementToken() as it is. Maybe do some 
checks with the web interface and crazy analyzers like Kuromoji or 
SmartTschinese :-)

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



--
This message was sent by Atlassian 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-8463) FacetComponent throw NPE when using shards.tolerant and a shard fails to respond

[Ran Peled (JIRA)]

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

Ran Peled updated SOLR-8463:

Flags: Patch

> FacetComponent throw NPE when using shards.tolerant and a shard fails to 
> respond
> 
>
> Key: SOLR-8463
> URL: https://issues.apache.org/jira/browse/SOLR-8463
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3.1
> Environment: Distributed Search
>Reporter: Ran Peled
> Attachments: SOLR-8463.patch
>
>
> When using shards.tolerant distributed search, and some shards fail to 
> respond, FacetComponent.handleResponses() throws NPE.
> This is similar to SOLR-1665: add distributed support, fixed in 4.10.



--
This message was sent by Atlassian 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-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8433:
--

Ok, thanks! Looks like I'll have to log this in another spot for it to appear 
in the logs.

> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
>[junit4]   2>  at 
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:480)
>[junit4]   2>  ... 11 more
>[junit4]   2> Caused by: sun.security.validator.ValidatorException: PKIX 
> path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>[junit4]   2>  at 
> sun.security.validator.Validator.validate(Validator.java:260)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
>[junit4]   2>  ... 29 more
>[junit4]   2> Caused by: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:146)
>[junit4]   2>  at 
> 

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7887:


[~thelabdude], I think it's time to work on this.  Your implementation of 
LogWatcher for log4j2 would be a prerequisite.  Should that be its own issue, 
or part of this one?

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
This message was sent by Atlassian 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 # 732 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 20454 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:784:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:130:
 Found 1 violations in source files (nocommit).

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



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

[jira] [Commented] (SOLR-8436) Realtime-get should support filters

[ASF subversion and git services (JIRA)]

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

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

Commit 1721593 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1721593 ]

SOLR-8436: remove nocommit

> Realtime-get should support filters
> ---
>
> Key: SOLR-8436
> URL: https://issues.apache.org/jira/browse/SOLR-8436
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk
>
> Attachments: SOLR-8436.patch, SOLR-8436.patch, SOLR-8436.patch, 
> SOLR-8436.patch
>
>
> RTG currently ignores filters.  There are probably other use-cases for RTG 
> and filters, but one that comes to mind is security filters.



--
This message was sent by Atlassian 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-8436) Realtime-get should support filters

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-8436.

   Resolution: Fixed
Fix Version/s: Trunk

> Realtime-get should support filters
> ---
>
> Key: SOLR-8436
> URL: https://issues.apache.org/jira/browse/SOLR-8436
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk
>
> Attachments: SOLR-8436.patch, SOLR-8436.patch, SOLR-8436.patch, 
> SOLR-8436.patch
>
>
> RTG currently ignores filters.  There are probably other use-cases for RTG 
> and filters, but one that comes to mind is security filters.



--
This message was sent by Atlassian 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 (32bit/jdk-9-ea+95) - Build # 15304 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 20450 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:784: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:130: Found 1 
violations in source files (nocommit).

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



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

[jira] [Commented] (SOLR-8436) Realtime-get should support filters

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8436:


bq. Couldn't you fill a BooleanQuery of FILTER clauses

Very common case will be just a single filter, plus boolean query has more 
overhead these days - not sure if it would matter or be worth it to try and 
match a single doc.  I'm not against it either, so feel free to take it if you 
want to make that change.

> Realtime-get should support filters
> ---
>
> Key: SOLR-8436
> URL: https://issues.apache.org/jira/browse/SOLR-8436
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk
>
> Attachments: SOLR-8436.patch, SOLR-8436.patch, SOLR-8436.patch, 
> SOLR-8436.patch
>
>
> RTG currently ignores filters.  There are probably other use-cases for RTG 
> and filters, but one that comes to mind is security filters.



--
This message was sent by Atlassian 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-8433) IterativeMergeStrategy test failures due to SSL errors on Windows

[ASF subversion and git services (JIRA)]

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

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

Commit 1721592 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1721592 ]

SOLR-8433: Move logging for HttpClientConfigurer

> IterativeMergeStrategy test failures due to SSL errors  on Windows
> --
>
> Key: SOLR-8433
> URL: https://issues.apache.org/jira/browse/SOLR-8433
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> The AnalyticsMergeStrageyTest is failing on Windows with SSL errors. The 
> failures are occurring during the callbacks to the shards introduced in 
> SOLR-6398.
> {code}
>   
> [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>[junit4]   2>  at 
> sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]   2>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
>[junit4]   2>  at 
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
>[junit4]   2>  at 
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
>[junit4]   2>  at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
>[junit4]   2>  at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
>[junit4]   2>  at 
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
>[junit4]   2>  at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
>[junit4]   2>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:480)
>[junit4]   2>  ... 11 more
>[junit4]   2> Caused by: sun.security.validator.ValidatorException: PKIX 
> path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>[junit4]   2>  at 
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>[junit4]   2>  at 
> sun.security.validator.Validator.validate(Validator.java:260)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>[junit4]   2>  at 
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>[junit4]   2>  at 
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
>[junit4]   2>  ... 29 more
>[junit4]   2> Caused by: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target
>[junit4]   2>  at 
> 

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

[Policeman Jenkins Server]

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

26 tests failed.
FAILED:  org.apache.solr.TestDistributedMissingSort.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:44550//collection1
at 
__randomizedtesting.SeedInfo.seed([C64DF4AA7E5CB845:4E19CB70D0A0D5BD]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
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:150)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:896)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:859)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:874)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:545)
at 
org.apache.solr.TestDistributedMissingSort.index(TestDistributedMissingSort.java:49)
at 
org.apache.solr.TestDistributedMissingSort.test(TestDistributedMissingSort.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:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 

Re: [JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 732 - Failure

[Yonik Seeley]

Oops, that's my nocommit... fixing.
-Yonik

On Wed, Dec 23, 2015 at 9:39 PM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/732/
>
> All tests passed
>
> Build Log:
> [...truncated 20454 lines...]
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:784:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/build.xml:130:
>  Found 1 violations in source files (nocommit).
>
> Total time: 71 minutes 34 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

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

[jira] [Updated] (SOLR-8459) NPE using TermVectorComponent in combinition with ExactStatsCache

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8459:
---
Attachment: SOLR-8459.patch

Trivial patch for this issue.
Querycomponent did not set rb.results because it is waiting for exact stats. So 
when termvectorcomponent get the result it got NPE.

> NPE using TermVectorComponent in combinition with ExactStatsCache
> -
>
> Key: SOLR-8459
> URL: https://issues.apache.org/jira/browse/SOLR-8459
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Andreas Daffner
> Attachments: SOLR-8459.patch
>
>
> Hello,
> I am getting a NPE when using the TermVectorComponent in combinition with 
> ExactStatsCache.
> I am using SOLR 5.3.0 with 4 shards in total.
> I set up my solrconfig.xml as described in these 2 links:
> TermVectorComponent:
> https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component
> ExactStatsCache:
> https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation
> My snippets from solrconfig.xml:
> {code}
> ...
>   
>   
>   
>class="org.apache.solr.handler.component.TermVectorComponent"/>
>class="org.apache.solr.handler.component.SearchHandler">
> 
>   true
> 
> 
>   tvComponent
> 
>   
> ...
> {code}
> Unfortunately a request to SOLR like 
> "http://host/solr/corename/tvrh?q=site_url_id:74; ends up with this NPE:
> {code}
> 4329458 ERROR (qtp59559151-17) [c:SingleDomainSite_11 s:shard1 r:core_node1 
> x:SingleDomainSite_11_shard1_replica1] o.a.s.c.SolrCore 
> java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:454)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:416)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:210)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> According to https://issues.apache.org/jira/browse/SOLR-7756 this Bug should 
> be fixed with SOLR 5.3.0, but obviously this NPE is still present.
> Can you please help me here?



--
This message was sent by Atlassian 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-8220) Read field from docValues for non stored fields

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8220:
--

LGTM as far as not returning all the DV values with each doc.



> Read field from docValues for non stored fields
> ---
>
> Key: SOLR-8220
> URL: https://issues.apache.org/jira/browse/SOLR-8220
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8220-5x.patch, SOLR-8220-ishan.patch, 
> SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, SOLR-8220-ishan.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch, 
> SOLR-8220.patch, SOLR-8220.patch, SOLR-8220.patch
>
>
> Many times a value will be both stored="true" and docValues="true" which 
> requires redundant data to be stored on disk. Since reading from docValues is 
> both efficient and a common practice (facets, analytics, streaming, etc), 
> reading values from docValues when a stored version of the field does not 
> exist would be a valuable disk usage optimization.
> The only caveat with this that I can see would be for multiValued fields as 
> they would always be returned sorted in the docValues approach. I believe 
> this is a fair compromise.
> I've done a rough implementation for this as a field transform, but I think 
> it should live closer to where stored fields are loaded in the 
> SolrIndexSearcher.
> Two open questions/observations:
> 1) There doesn't seem to be a standard way to read values for docValues, 
> facets, analytics, streaming, etc, all seem to be doing their own ways, 
> perhaps some of this logic should be centralized.
> 2) What will the API behavior be? (Below is my proposed implementation)
> Parameters for fl:
> - fl="docValueField"
>   -- return field from docValue if the field is not stored and in docValues, 
> if the field is stored return it from stored fields
> - fl="*"
>   -- return only stored fields
> - fl="+"
>-- return stored fields and docValue fields
> 2a - would be easiest implementation and might be sufficient for a first 
> pass. 2b - is current behavior



--
This message was sent by Atlassian 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-8436) Realtime-get should support filters

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-8436:


I was looking at the loop you have on the filters and advancing each scorer one 
by one... Couldn't you fill a BooleanQuery of FILTER clauses and more simply do 
this on one Query and thus also leverage the logic BooleanQuery has on costs & 
two-phase iterators?

> Realtime-get should support filters
> ---
>
> Key: SOLR-8436
> URL: https://issues.apache.org/jira/browse/SOLR-8436
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: Trunk
>
> Attachments: SOLR-8436.patch, SOLR-8436.patch, SOLR-8436.patch, 
> SOLR-8436.patch
>
>
> RTG currently ignores filters.  There are probably other use-cases for RTG 
> and filters, but one that comes to mind is security filters.



--
This message was sent by Atlassian 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-6948) ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill

[Michael Lawley (JIRA)]

Michael Lawley created LUCENE-6948:
--

 Summary: ArrayIndexOutOfBoundsException in PagedBytes$Reader.fill
 Key: LUCENE-6948
 URL: https://issues.apache.org/jira/browse/LUCENE-6948
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: 4.10.4
Reporter: Michael Lawley


With a very large index (in our case > 10G), we are seeing exceptions like:

java.lang.ArrayIndexOutOfBoundsException: -62400
at org.apache.lucene.util.PagedBytes$Reader.fill(PagedBytes.java:116)
at 
org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get(FieldCacheImpl.java:1342)
at 
org.apache.lucene.search.join.TermsCollector$SV.collect(TermsCollector.java:106)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:193)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:309)

The code in question is trying to allocate an array with a negative size.  We 
believe the source of the error is in 
org.apache.lucene.search.FieldCacheImpl$BinaryDocValuesImpl$1.get where the 
following code occurs:

  final int pointer = (int) docToOffset.get(docID);
  if (pointer == 0) {
term.length = 0;
  } else {
bytes.fill(term, pointer);
  }

The cast to int will break if the (long) result of docToOffset.get is too 
large, and is unnecessary in the first place since bytes.fill takes a long as 
its second parameter.

Proposed fix:

  final long pointer = docToOffset.get(docID);
  if (pointer == 0) {
term.length = 0;
  } else {
bytes.fill(term, pointer);
  }





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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15305/
Java: 32bit/jdk-9-ea+95 -client -XX:+UseSerialGC -XX:-CompactStrings

All tests passed

Build Log:
[...truncated 20455 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:784: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:130: Found 1 
violations in source files (nocommit).

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



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

[jira] [Updated] (LUCENE-6940) Bulk scoring could speed up MUST_NOT clauses

[Adrien Grand (JIRA)]

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

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

Here is a new patch. This time it has tests and tries to organize the code a 
bit better. Tests pass and luceneutil still reports similar times (this time I 
only ran the default tasks for wikimedium10m):

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
   OrNotHighHigh   35.34  (2.2%)   32.99  (3.3%)   
-6.7% ( -11% -   -1%)
OrNotHighMed  174.57  (2.3%)  170.17  (1.8%)   
-2.5% (  -6% -1%)
   OrHighMed   73.34  (4.6%)   72.13  (5.0%)   
-1.7% ( -10% -8%)
  OrHighHigh9.17  (5.7%)9.03  (5.2%)   
-1.5% ( -11% -9%)
   OrHighNotHigh   78.91  (2.8%)   78.16  (3.6%)   
-0.9% (  -7% -5%)
   OrHighLow   19.79  (2.7%)   19.73  (3.6%)   
-0.3% (  -6% -6%)
 LowSloppyPhrase   70.26  (2.1%)   70.14  (2.3%)   
-0.2% (  -4% -4%)
  AndHighMed  191.70  (1.7%)  191.59  (1.7%)   
-0.1% (  -3% -3%)
 AndHighHigh   79.74  (1.0%)   79.79  (0.9%)
0.1% (  -1% -1%)
 MedSloppyPhrase   73.28  (2.5%)   73.37  (2.7%)
0.1% (  -5% -5%)
 Respell   84.33  (2.4%)   84.60  (2.8%)
0.3% (  -4% -5%)
 LowSpanNear   12.79  (3.9%)   12.83  (3.0%)
0.4% (  -6% -7%)
   LowPhrase   48.59  (1.2%)   48.79  (1.2%)
0.4% (  -2% -2%)
   MedPhrase   33.55  (1.4%)   33.71  (1.3%)
0.5% (  -2% -3%)
HighSpanNear   14.50  (3.2%)   14.60  (2.6%)
0.7% (  -4% -6%)
 MedSpanNear  151.02  (3.3%)  152.17  (1.7%)
0.8% (  -4% -5%)
HighSloppyPhrase   15.76  (5.3%)   15.90  (5.2%)
0.9% (  -9% -   12%)
  HighPhrase   32.51  (2.3%)   33.09  (1.4%)
1.8% (  -1% -5%)
 Prefix3   90.59  (8.9%)   92.74  (7.5%)
2.4% ( -12% -   20%)
Wildcard  125.13  (8.2%)  128.21  (7.8%)
2.5% ( -12% -   20%)
 MedTerm  291.05  (6.8%)  300.34  (6.5%)
3.2% (  -9% -   17%)
  Fuzzy1   61.93  (8.8%)   64.08  (9.6%)
3.5% ( -13% -   23%)
HighTerm   79.63  (7.3%)   83.28  (6.9%)
4.6% (  -8% -   20%)
  IntNRQ   10.39 (13.8%)   10.94 (11.5%)
5.3% ( -17% -   35%)
 LowTerm  575.82 (12.7%)  607.32 (10.6%)
5.5% ( -15% -   33%)
OrNotHighLow  985.95  (4.4%) 1054.73  (3.0%)
7.0% (   0% -   15%)
  AndHighLow  688.12  (8.2%)  736.65  (4.5%)
7.1% (  -5% -   21%)
  Fuzzy2   58.94 (14.4%)   63.15  (8.9%)
7.2% ( -14% -   35%)
OrHighNotMed   84.50  (3.4%)   95.46  (3.8%)   
13.0% (   5% -   20%)
OrHighNotLow   64.23  (3.3%)   76.36  (4.7%)   
18.9% (  10% -   27%)
{noformat}

> Bulk scoring could speed up MUST_NOT clauses
> 
>
> Key: LUCENE-6940
> URL: https://issues.apache.org/jira/browse/LUCENE-6940
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6940.patch, LUCENE-6940.patch
>
>
> Today when you have MUST_NOT clauses, the ReqExclScorer is used and needs to 
> check the excluded clauses on every iteration. I suspect we could speed 
> things up by having a BulkScorer that would advance the excluded clause first 
> and then tell the required clause to bulk score up to the next excluded 
> document.



--
This message was sent by Atlassian 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-8436) Realtime-get should support filters

[ASF subversion and git services (JIRA)]

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

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

Commit 1721585 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1721585 ]

SOLR-8436: filters for realtime-get

> Realtime-get should support filters
> ---
>
> Key: SOLR-8436
> URL: https://issues.apache.org/jira/browse/SOLR-8436
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Attachments: SOLR-8436.patch, SOLR-8436.patch, SOLR-8436.patch, 
> SOLR-8436.patch
>
>
> RTG currently ignores filters.  There are probably other use-cases for RTG 
> and filters, but one that comes to mind is security filters.



--
This message was sent by Atlassian 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-8439) Solr Security - Permission read does not work as expected

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8439:


bq. Is it possible to backport it to 5.3.1?

5.3.1 has been released and will not be changing.

A 5.3.2 release is coming soon, though.  A bunch of fixes, including SOLR-8617, 
*will* be backported to the 5.3 branch, and 5.3.2 will most likely be announced 
within the next 2-3 weeks.  Upgrading to 5.4.0 is still recommended, as it 
includes more changes and fixes than 5.3.2 will.

> Solr Security - Permission read does not work as expected
> -
>
> Key: SOLR-8439
> URL: https://issues.apache.org/jira/browse/SOLR-8439
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3.1
> Environment: Linux, Solr Cloud
>Reporter: Gaurav Kumar
>Priority: Critical
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> I enabled security on my solr cloud and added basic authentication and 
> authorization to allow only specific users to read and update the records. 
> What I observed that update works fine but read does not stop from anonymous 
> access. 
> On digging deeper I saw that RuleBasedAuthorizationPlugin.java has 
> incorrectly defined the read permissions as follows:
> read :{" +
>   "  path:['/update/*', '/get']}," +
> It should be /select/* rather than /update/*



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

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_66) - Build # 15288 - Failure!

[Michael McCandless]

I committed a fix.

Mike McCandless

http://blog.mikemccandless.com


On Wed, Dec 23, 2015 at 5:56 AM, Steve Rowe  wrote:
> Another reproducible failure from my Jenkins:
>
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestDimensionalRangeQuery 
> -Dtests.method=testAllDimensionalDocsWereDeletedAndThenMergedAgain 
> -Dtests.seed=B398F471D8C24FB2 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=zh_SG -Dtests.timezone=Asia/Damascus -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.22s | 
> TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain 
> <<<
>[junit4]> Throwable #1: java.lang.IllegalStateException: must index at 
> least one point
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([B398F471D8C24FB2:5CE55CC1B5D7B2F]:0)
>[junit4]>at 
> org.apache.lucene.util.bkd.BKDWriter.finish(BKDWriter.java:742)
>[junit4]>at 
> org.apache.lucene.codecs.simpletext.SimpleTextDimensionalWriter.writeField(SimpleTextDimensionalWriter.java:160)
>[junit4]>at 
> org.apache.lucene.codecs.DimensionalWriter.mergeOneField(DimensionalWriter.java:44)
>[junit4]>at 
> org.apache.lucene.codecs.DimensionalWriter.merge(DimensionalWriter.java:106)
>[junit4]>at 
> org.apache.lucene.index.SegmentMerger.mergeDimensionalValues(SegmentMerger.java:168)
>[junit4]>at 
> org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:117)
>[junit4]>at 
> org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4062)
>[junit4]>at 
> org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
>[junit4]>at 
> org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
>[junit4]>at 
> org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
>[junit4]>at 
> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
>[junit4]>at 
> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
>[junit4]>at 
> org.apache.lucene.search.TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain(TestDimensionalRangeQuery.java:1003)
>[junit4]>at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> NOTE: test params are: codec=SimpleText, 
> sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, locale=zh_SG, 
> timezone=Asia/Damascus
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_45 (64-bit)/cpus=16,threads=1,free=426065104,total=514850816
>[junit4]   2> NOTE: All tests run in this JVM: [TestDimensionalRangeQuery]
>[junit4] Completed [1/1 (1!)] in 0.41s, 1 test, 1 error <<< FAILURES!
>
>
>
>> On Dec 22, 2015, at 2:36 PM, Michael McCandless  
>> wrote:
>>
>> I'll dig
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Tue, Dec 22, 2015 at 11:40 AM, Policeman Jenkins Server
>>  wrote:
>>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15288/
>>> Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseSerialGC
>>>
>>> 1 tests failed.
>>> FAILED:  
>>> org.apache.lucene.search.TestDimensionalRangeQuery.testAllDimensionalDocsWereDeletedAndThenMergedAgain
>>>
>>> Error Message:
>>> must index at least one point
>>>
>>> Stack Trace:
>>> java.lang.IllegalStateException: must index at least one point
>>>at 
>>> __randomizedtesting.SeedInfo.seed([AAC8CFA944E142D1:1C9E6E14877E764C]:0)
>>>at org.apache.lucene.util.bkd.BKDWriter.finish(BKDWriter.java:742)
>>>at 
>>> org.apache.lucene.codecs.simpletext.SimpleTextDimensionalWriter.writeField(SimpleTextDimensionalWriter.java:160)
>>>at 
>>> org.apache.lucene.codecs.DimensionalWriter.mergeOneField(DimensionalWriter.java:44)
>>>at 
>>> org.apache.lucene.codecs.DimensionalWriter.merge(DimensionalWriter.java:106)
>>>at 
>>> org.apache.lucene.index.SegmentMerger.mergeDimensionalValues(SegmentMerger.java:168)
>>>at 
>>> org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:117)
>>>at 
>>> org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4062)
>>>at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3642)
>>>at 
>>> org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
>>>at 
>>> org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1917)
>>>at 
>>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1750)
>>>at 
>>> org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1707)
>>>at 
>>> 

[jira] [Commented] (SOLR-8439) Solr Security - Permission read does not work as expected

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8439:


Made a typo.  The comment edit option is missing, probably because the issue is 
closed.

SOLR-8617 should have been SOLR-8167.

> Solr Security - Permission read does not work as expected
> -
>
> Key: SOLR-8439
> URL: https://issues.apache.org/jira/browse/SOLR-8439
> Project: Solr
>  Issue Type: Bug
>  Components: security
>Affects Versions: 5.3.1
> Environment: Linux, Solr Cloud
>Reporter: Gaurav Kumar
>Priority: Critical
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> I enabled security on my solr cloud and added basic authentication and 
> authorization to allow only specific users to read and update the records. 
> What I observed that update works fine but read does not stop from anonymous 
> access. 
> On digging deeper I saw that RuleBasedAuthorizationPlugin.java has 
> incorrectly defined the read permissions as follows:
> read :{" +
>   "  path:['/update/*', '/get']}," +
> It should be /select/* rather than /update/*



--
This message was sent by Atlassian 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-8460) /analysis/field doesn't always handle custom attributes correctly

[David Smiley (JIRA)]

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

David Smiley updated SOLR-8460:
---
Attachment: SOLR_8460.patch

In this updated patch, I ensured that attributes are added in incrementToken 
too.

However I kept it using addAttributeImpl, with the following comment:
{noformat}
  // note: ideally we wouldn't call addAttributeImpl which is marked 
internal. But nonetheless it's possible
  //  this method is used by some custom attributes, especially since Solr 
doesn't provide a way to customize the
  //  AttributeFactory which is the recommended way to choose which classes 
implement which attributes.
{noformat}

> /analysis/field doesn't always handle custom attributes correctly
> -
>
> Key: SOLR-8460
> URL: https://issues.apache.org/jira/browse/SOLR-8460
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 5.5
>
> Attachments: SOLR_8460.patch, SOLR_8460.patch
>
>
> I've got some custom analysis Attribute implementations in my analysis chain 
> with some other custom analysis components.  I found that Solr's Analysis 
> utility screen, powered by /field/analysis (FieldAnalysisRequestHandler 
> subclassing AnalysisRequestHandlerBase) gave me exceptions for two reasons, 
> both having to do with AnalysisRequestHandlerBase.ListBasedTokenStream:
> * Custom implementations of standard Attributes (e.g. FlagsAttribute) would 
> trigger an exception.
> * Calling getAttribute (instead of addAttribute) in a TokenFilter constructor 
> wouldn't find an attribute added by the input TokenStream.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2961/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.search.AnalyticsMergeStrategyTest.test

Error Message:
Error from server at http://127.0.0.1:64909/son/xp/collection1: 
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Scheme 'http' not registered.

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:64909/son/xp/collection1: 
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
Scheme 'http' not registered.
at 
__randomizedtesting.SeedInfo.seed([C8EE6BB70EF0E676:40BA546DA00C8B8E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
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:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:562)
at 
org.apache.solr.search.AnalyticsMergeStrategyTest.test(AnalyticsMergeStrategyTest.java:85)
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:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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 

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1055 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1055/

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:47131/phpp/collection1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:47131/phpp/collection1]
at 
__randomizedtesting.SeedInfo.seed([DDD71E7F89D6D30C:558321A5272ABEF4]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1378)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:101)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:73)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:52)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15306/
Java: 32bit/jdk-9-ea+95 -client -XX:+UseG1GC -XX:-CompactStrings

8 tests failed.
FAILED:  org.apache.solr.client.solrj.TestBatchUpdate.testWithBinaryBean

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:49708/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([9880F074A877AA3C:FB6BF176C8136D1E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
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:150)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:896)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:859)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:874)
at 
org.apache.solr.client.solrj.TestBatchUpdate.testWithBinaryBean(TestBatchUpdate.java:70)
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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 

[jira] [Commented] (SOLR-8455) Improve RecoveryStrategy logging and fix interval-between-recovery-attempts

[ASF subversion and git services (JIRA)]

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

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

Commit 1721533 from [~shaie] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1721533 ]

SOLR-8455: Improve RecoveryStrategy logging and fix 
interval-between-recovery-attempts

> Improve RecoveryStrategy logging and fix interval-between-recovery-attempts
> ---
>
> Key: SOLR-8455
> URL: https://issues.apache.org/jira/browse/SOLR-8455
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8455.patch, SOLR-8455.patch
>
>
> This issue addresses multiple minor improvements to {{RecoveryStrategy}}:
> * Logging improvements: proper use of Logger interface, improve log messages.
> * Consolidated a debug block into a method and reuse.
> * Get rid of unused and deprecated code.
> In addition, the code over-slept between recovery attempts. The inline 
> comment suggested that the intention was to sleep between 1 second to 1 
> minute, while implement an exponential sleep interval strategy. However in 
> practice the code sleeps in intervals of 5 seconds and up to 5 minutes. So I 
> fixed the code to sleep at interval of 5 seconds (checking if it was closed 
> in between sleep attempts) and up to 1 minute.



--
This message was sent by Atlassian 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-7339) Upgrade Jetty from 9.2 to 9.3

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7339:
-

bq. We should probably try and isolate what is causing it so we can file a bug, 
but we would still need to wait for a good version.

...maybe suggest to Jetty people that they use forbidden-apis with 
{{jdk-unsafe}} bundled signatures! :-)

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
This message was sent by Atlassian 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-8455) Improve RecoveryStrategy logging and fix interval-between-recovery-attempts

[Shai Erera (JIRA)]

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

Shai Erera resolved SOLR-8455.
--
Resolution: Fixed

Committed to trunk and 5x.

> Improve RecoveryStrategy logging and fix interval-between-recovery-attempts
> ---
>
> Key: SOLR-8455
> URL: https://issues.apache.org/jira/browse/SOLR-8455
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8455.patch, SOLR-8455.patch
>
>
> This issue addresses multiple minor improvements to {{RecoveryStrategy}}:
> * Logging improvements: proper use of Logger interface, improve log messages.
> * Consolidated a debug block into a method and reuse.
> * Get rid of unused and deprecated code.
> In addition, the code over-slept between recovery attempts. The inline 
> comment suggested that the intention was to sleep between 1 second to 1 
> minute, while implement an exponential sleep interval strategy. However in 
> practice the code sleeps in intervals of 5 seconds and up to 5 minutes. So I 
> fixed the code to sleep at interval of 5 seconds (checking if it was closed 
> in between sleep attempts) and up to 1 minute.



--
This message was sent by Atlassian 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-8420) Date statistics: sumOfSquares overflows long

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8420:
---

sumOfSquares overflow, interesting. I wonder if {{DateStatsValues}}'s {{private 
long sum = 0;}} might perhaps become {{double}} also (similar to 
{{NumericStatsValues}}'s sum being a double already).

> Date statistics: sumOfSquares overflows long
> 
>
> Key: SOLR-8420
> URL: https://issues.apache.org/jira/browse/SOLR-8420
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.4
>Reporter: Tom Hill
>Priority: Minor
> Attachments: 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, StdDev.java
>
>
> The values for Dates are large enough that squaring them overflows a "long" 
> field. This should be converted to a double. 
> StatsValuesFactory.java, line 755 DateStatsValues#updateTypeSpecificStats Add 
> a cast to double 
> sumOfSquares += ( (double)value * value * count);



--
This message was sent by Atlassian 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-6945) factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename TestParser to TestCoreParser

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-6945:

Summary: factor out TestCorePlus(Queries|Extensions)Parser from TestParser, 
rename TestParser to TestCoreParser  (was: factor out 
TestCorePlus(Queries|Extensions)Parser from TestParser)

> factor out TestCorePlus(Queries|Extensions)Parser from TestParser, rename 
> TestParser to TestCoreParser
> --
>
> Key: LUCENE-6945
> URL: https://issues.apache.org/jira/browse/LUCENE-6945
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6945.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} or {{TestCorePlusQueriesParser}} or 
> {{TestCorePlusExtensionsParser}} depending on requirements.



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

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

[jira] [Reopened] (LUCENE-6945) factor out TestCorePlus(Queries|Extensions)Parser from TestParser

[Christine Poerschke (JIRA)]

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

Christine Poerschke reopened LUCENE-6945:
-

Re-opening, I had also intended to rename {{TestParser}} to {{TestCoreParser}} 
since that is now its purpose and scope.

> factor out TestCorePlus(Queries|Extensions)Parser from TestParser
> -
>
> Key: LUCENE-6945
> URL: https://issues.apache.org/jira/browse/LUCENE-6945
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Fix For: 5.5, Trunk
>
> Attachments: LUCENE-6945.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} or {{TestCorePlusQueriesParser}} or 
> {{TestCorePlusExtensionsParser}} depending on requirements.



--
This message was sent by Atlassian 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-8455) Minor improvements to RecoveryStrategy

[Shai Erera (JIRA)]

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

Shai Erera updated SOLR-8455:
-
Attachment: SOLR-8455.patch

Patch updated with a CHANGES record. If there are no objections, I will commit 
it soon.

> Minor improvements to RecoveryStrategy
> --
>
> Key: SOLR-8455
> URL: https://issues.apache.org/jira/browse/SOLR-8455
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, Trunk
>
> Attachments: SOLR-8455.patch, SOLR-8455.patch
>
>
> This issue addresses multiple minor improvements to {{RecoveryStrategy}}:
> * Logging improvements: proper use of Logger interface, improve log messages.
> * Consolidated a debug block into a method and reuse.
> * Get rid of unused and deprecated code.
> In addition, the code over-slept between recovery attempts. The inline 
> comment suggested that the intention was to sleep between 1 second to 1 
> minute, while implement an exponential sleep interval strategy. However in 
> practice the code sleeps in intervals of 5 seconds and up to 5 minutes. So I 
> fixed the code to sleep at interval of 5 seconds (checking if it was closed 
> in between sleep attempts) and up to 1 minute.



--
This message was sent by Atlassian 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-5716) Track file handle leaks (FileDescriptor, NIO Path SPI and Socket mostly).

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-5716:
-

This is just a note to self. I requested an open source license for the most 
recent YourKit profiler (graciously donated by the company -- yay!). There is a 
new feature I haven't seen before -- probes, exactly in the shape and form I 
always imagined them to be (I have been a fan of aspectj, but this is done via 
agents, so it allows modifications of system classes I believe).

Very cool. This could be used to track other resource leaks (sockets, etc.). If 
combined with JUnit rules, it could even detect such leaks at class or method 
level.

https://www.yourkit.com/docs/java/help/probes.jsp
https://www.yourkit.com/docs/java/help/event_method_call.jsp

> Track file handle leaks (FileDescriptor, NIO Path SPI and Socket mostly).
> -
>
> Key: LUCENE-5716
> URL: https://issues.apache.org/jira/browse/LUCENE-5716
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>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