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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1096/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 13189 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/temp/junit4-J0-20170125_063949_6198742212180168337133.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.security.PrivilegedActionException: java.io.IOException: No space left on 
device
   [junit4] at java.security.AccessController.doPrivileged(Native Method)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:114)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:99)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$3$2.write(SlaveMain.java:459)
   [junit4] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
   [junit4] at 
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
   [junit4] at java.io.PrintStream.flush(PrintStream.java:338)
   [junit4] at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
   [junit4] at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
   [junit4] at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
   [junit4] at 
org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:59)
   [junit4] at 
org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:324)
   [junit4] at 
org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
   [junit4] at 
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
   [junit4] at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
   [junit4] at org.apache.log4j.Category.callAppenders(Category.java:206)
   [junit4] at org.apache.log4j.Category.forcedLog(Category.java:391)
   [junit4] at org.apache.log4j.Category.log(Category.java:856)
   [junit4] at 
org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
   [junit4] at org.apache.solr.core.SolrCore.execute(SolrCore.java:2407)
   [junit4] at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
   [junit4] at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
   [junit4] at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
   [junit4] at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
   [junit4] at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
   [junit4] at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:113)
   [junit4] 
   [junit4] at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
   [junit4] at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
   [junit4] at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
   [junit4] at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
   [junit4] at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
   [junit4] at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
   [junit4] at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
   [junit4] at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
   [junit4] at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)
   [junit4] at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
   [junit4] at org.eclipse.jetty.server.Server.handle(Server.java:534)
   [junit4] at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
   [junit4] at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
   [junit4] at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
   [junit4] at 
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
   [junit4] at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
   [junit4] at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
   [junit4] at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
   [junit4] at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
   [junit4] at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
   [junit4] at

Re: [jira] [Commented] (SOLR-6761) Ability to ignore commit and optimize requests from clients when running in SolrCloud mode.

2017-01-24 Thread Ishan Chattopadhyaya 
> Recommendation shouldn’t be enforced
I think the discussion is just about adding the ability to ignore such
requests, not ignoring them by default.

My suggestion, in the case when admins don't want regular users to
commit/optimize, is to enable authorization and hence allow/disallow only
certain users from issuing such commands.

On Mon, Jan 23, 2017 at 10:09 PM, Yago Riveiro 
wrote:

> -1 for this.
>
> I don’t understand why I can do a optimize over a collection when I want,
> with or without penalty of performance.
>
>
> In indexes with a high ratio of deletes the only way to reclaim space is
> with the optimize command, and yes, sometimes I need to run this command to
> reclaim 100 or 200G of space from my SSD’s … And yes I know that merge
> operations removes the deletes, but if you have segments with 100G, and
> deletes on them you never going to hit this segment in a merge until merge
> the X others that the index has.
>
> Recommendation shouldn’t be enforced, this is the main point of a
> “recommendation”.
>
> Regards,
>
> --
>
> /Yago Riveiro
>
> On 23 Jan 2017 14:26 +, karney luo (JIRA) , wrote:
>
>
> [ https://issues.apache.org/jira/browse/SOLR-6761?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15834652#comment-15834652 ]
>
> karney luo commented on SOLR-6761:
> --
>
> 谢谢您的来信，罗昆仲已经收到
>
>
> Ability to ignore commit and optimize requests from clients when running
> in SolrCloud mode.
> 
> ---
>
> Key: SOLR-6761
> URL: https://issues.apache.org/jira/browse/SOLR-6761
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud, SolrJ
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Fix For: 5.0, 6.0
>
> Attachments: SOLR-6761.patch, SOLR-6761.patch
>
>
> In most SolrCloud environments, it's advisable to only rely on
> auto-commits (soft and hard) configured in solrconfig.xml and not send
> explicit commit requests from client applications. In fact, I've seen cases
> where improperly coded client applications can send commit requests too
> frequently, which can lead to harming the cluster's health.
> As a system administrator, I'd like the ability to disallow commit
> requests from client applications. Ideally, I could configure the
> updateHandler to ignore the requests and return an HTTP response code of my
> choosing as I may not want to break existing client applications by
> returning an error. In other words, I may want to just return 200 vs. 405.
> The same goes for optimize requests.
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3796/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([8A52E9F8E7C49C15:206D6224938F1ED]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at

Re: Lucene/Solr 7

2017-01-24 Thread David Smiley 
LOL, "ambiguous" perhaps; I don't think "dangerous".

+1 to Adrien's plan.

On Tue, Jan 24, 2017 at 2:04 PM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Early may is exactly what I meant by "a few months".
>
> I guess "few" is a dangerous word!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Jan 24, 2017 at 1:02 PM, Joel Bernstein 
> wrote:
> > I was feeling more comfortable with the early may timeframe.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> > On Tue, Jan 24, 2017 at 12:43 PM, Michael McCandless
> >  wrote:
> >>
> >> +1 to push 7.0 out in a few months...
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Tue, Jan 24, 2017 at 11:52 AM, Adrien Grand 
> wrote:
> >> > Hi all,
> >> >
> >> > We have accumulated some good changes in master, like point support in
> >> > Solr
> >> > or sparse norms/doc-values in Lucene. I think it would be nice to
> expose
> >> > these new features to our users, so what would you think about
> starting
> >> > to
> >> > work on making master ready to be released?
> >> >
> >> > Since the question about the timeframe will be asked, I think we could
> >> > target something like early May 2017, which is a bit more than 3
> months
> >> > away
> >> > from now. What do you think?
> >> >
> >> > Adrien
> >>
> >> -
> >> 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
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 266 - Failure

2017-01-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/266/

5 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:753)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:767)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3198)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit(TestIndexingSequenceNumbers.java:230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([9D92D2FD78C8F5D3]:0)
at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsIndexWriter.(CompressingStoredFieldsIndexWriter.java:94)
at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.(CompressingStoredFieldsWriter.java:127)
at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:128)
at

Missing hyperlinks in Solr 6.4 release notes (html version)

2017-01-24 Thread Alexandre Rafalovitch 
I just noticed that in the HTML version of the shipped release notes,
the "LUCENE_CHANGES.txt" is no longer hyperlinked to the online
version of the Lucene changes document.

In the 6.3 release and before, it was hyperlinked.

I am not sure if that's a perl script change, missed process step or
something else. So, I am not clear whether the next step is a JIRA or
whether this email is sufficient.

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced

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

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6369/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestConfigSets

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001\core-reload:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001\core-reload

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001\core-reload:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001\core-reload
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSets_A42D812ABBE0084F-001\init-core-data-001

at __randomizedtesting.SeedInfo.seed([A42D812ABBE0084F]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:323)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.metrics.SolrMetricManagerTest.testClearMetrics

Error Message:
expected:<65> but was:<66>

Stack Trace:
java.lang.AssertionError: expected:<65> but was:<66>
at 
__randomizedtesting.SeedInfo.seed([A42D812ABBE0084F:E08F0695C387F3BF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.metrics.SolrMetricManagerTest.testClearMetrics(SolrMetricManagerTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

2017-01-24 Thread Mark Miller (JIRA) 

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

Mark Miller commented on SOLR-9555:
---

bq. The potential downside here is that we end up keeping two copies of the 
state, but I think it's ok? One is what the replica thinks it is, and one is 
what the leader thinks it is

I'm not sure if we really have to end up doing that. We already are 
communicating in ZK in a way that the replica can see itself it needs to enter 
recovery. I think we just need a strategy for the replica to have watches that 
alert it the leader has put it in LIR. The first time it notices this, it can 
be sure to go into recovery - it may even be better to only do that and remove 
the code that has the leader ask the replica to go into recovery on each 
failure. I think we can do that by pre creating some base LIR nodes and then 
watch it's children or something along those lines. Each LIR node in ZK could 
have a unique version so that we could tell if a new LIR request came in while 
responding to one (so start recovery over).

We should assume the replica can simply be alerted to mark itself as down when 
it sees it's been marked on LIR. If its too messed up to do that, it should 
lose it's zk connection, and if not, I think that's a corner case that needs an 
alternate solution.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(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-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

2017-01-24 Thread Mike Drob (JIRA) 

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

Mike Drob commented on SOLR-9555:
-

I've been thinking about this a bunch and have some observations.

We already have special nodes for LIR. It looks like these are currently only 
checked during leader election (or more generally, core load). If we instead 
have replicas watch for this at all times, then we wouldn't need to forcefully 
publish a down state, we could publish a down LIR state. Does this model move 
the race instead of eliminating it though? Alan's sequence would look like:
* A node goes down, and then restarts
* The leader tries to send a document to the starting node, and gets a 503 'not 
ready yet'
* The node publishes its state as RECOVERING
* The leader's LIR thread publishes the recovery node's LIR state as DOWN
* The node sends a PREPRECOVERY request to the leader
* The leader waits for the node's state to be RECOVERING, which it already is, 
and can proceed.
* At some point (possibly already happened) node sees new LIR state and 
abandons current recovery and starts a new one.

In the case where we get an error during recovery, the recovering replica would 
know to restart recovery process, so that works too.

We would also need to keep the Active state in the LIR path instead of deleting 
it so that there is a node we that replicas can set a watcher on.

The potential downside here is that we end up keeping two copies of the state, 
but I think it's ok? One is what the replica thinks it is, and one is what the 
leader thinks it is. I'll keep thinking about this more, but I wonder if 
there's a way to condense all these operations down to one znode safely.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(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-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SOLR-10026:
---

Github user johnthcall closed the pull request at:

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


> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0), 6.5
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



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

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

[GitHub] lucene-solr pull request #142: SOLR-10026 - JavaBinCodec should initialize m...

2017-01-24 Thread johnthcall 
Github user johnthcall closed the pull request at:

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


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

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

[jira] [Commented] (LUCENE-6959) Remove ToParentBlockJoinCollector

2017-01-24 Thread Martijn van Groningen (JIRA) 

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

Martijn van Groningen commented on LUCENE-6959:
---

+1 To remove this collector in the master and 6x branches.

As a follow up issue we can add back to ability to include child docs, but in a 
different way than is done today. A subsequent search after the main search, 
that selects child docs for specific parents. For example like is done here: 
https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/search/fetch/subphase/InnerHitsContext.java#L160

> Remove ToParentBlockJoinCollector
> -
>
> Key: LUCENE-6959
> URL: https://issues.apache.org/jira/browse/LUCENE-6959
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6959.patch
>
>
> This collector uses the getWeight() and getChildren() methods from the passed 
> in Scorer, which are not always available (eg. disjunctions expose fake 
> scorers) hence the need for a dedicated IndexSearcher 
> (ToParentBlockJoinIndexSearcher). Given that this is the only collector in 
> this case, I would like to 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

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/632/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=22825, name=jetty-launcher-3386-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=22825, name=jetty-launcher-3386-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
at __randomizedtesting.SeedInfo.seed([17B30A12BD1077FF]:0)




Build Log:
[...truncated 12424 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_17B30A12BD1077FF-001/init-core-data-001
   [junit4]   2> 2763964 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[17B30A12BD1077FF]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 2764008 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[17B30A12BD1077FF]-worker) [   
 ] o.a.s.c.MiniSolrCloudCluster Starting cluster of 2 servers in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_17B30A12BD1077FF-001/tempDir-001
   [junit4]   2> 2764009 INFO

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1095/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancelFail

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

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([2E9385B7DD1AD69A:462CB09D0D80C476]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.cancelDelegationToken(TestDelegationWithHadoopAuth.java:128)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenCancelFail(TestDelegationWithHadoopAuth.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Updated] (SOLR-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread Noble Paul (JIRA) 

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

Noble Paul updated SOLR-10026:
--
Fix Version/s: 6.5

> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0), 6.5
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



--
This message was sent by Atlassian JIRA
(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-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on SOLR-10026:


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

SOLR-10026: JavaBinCodec should initialize maps and namedLists with known 
capacity


> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0), 6.5
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



--
This message was sent by Atlassian JIRA
(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-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread Noble Paul (JIRA) 

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

Noble Paul resolved SOLR-10026.
---
Resolution: Fixed

> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0), 6.5
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



--
This message was sent by Atlassian JIRA
(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-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on SOLR-10026:


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

SOLR-10026: JavaBinCodec should initialize maps and namedLists with known 
capacity


> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0)
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



--
This message was sent by Atlassian JIRA
(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-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

2017-01-24 Thread Steve Rowe (JIRA) 

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

Steve Rowe updated SOLR-6246:
-
Attachment: SOLR-6246-test.patch

Patch that adds a random dictionary with configurable size and new tests that 
use it: 

# A build/reload test for each of {{AnalyzingInfixSuggester}} and 
{{BlendedInfixSuggester}}.
# A test that starts building a suggester in the background then initiates a 
core reload.

All the tests fail now. The first two only fail 50% of the time, with the cause 
given in others' reports on this issue; I'm not sure why they don't fail all 
the time.  (My earlier report of the previous test patch passing may have been 
luck/insufficient trials?).  The reload-while-building test sometimes finishes 
building, and then fails like the other tests, but sometimes reload causes the 
suggester's index writer to be closed, which causes an exception to be thrown, 
interrupting the build process.

For some reason, the suggesters' sidecar indexes have {{write.lock}} files in 
them even after {{writer.close()}} is called.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
> Attachments: SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(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-10026) JavaBinCodec should initialize maps and namedLists with known capacity

2017-01-24 Thread Noble Paul (JIRA) 

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

Noble Paul reassigned SOLR-10026:
-

Assignee: Noble Paul

> JavaBinCodec should initialize maps and namedLists with known capacity
> --
>
> Key: SOLR-10026
> URL: https://issues.apache.org/jira/browse/SOLR-10026
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.3, master (7.0)
>Reporter: John Call
>Assignee: Noble Paul
>Priority: Minor
>  Labels: javabincodec
> Fix For: master (7.0)
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> When unmarshalling maps and namedLists the size of theses lists are known but 
> the constructors for initializing these maps and namedLists with a 
> initialSize are not used.



--
This message was sent by Atlassian 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: Inquiry for Solr Cloud Authentication

2017-01-24 Thread Noble Paul 
Yes, you should setup basic auth without SSL it in a very protected network
only

On Wed, Jan 25, 2017 at 3:27 AM, Steve Davids  wrote:

> Don't let "basic auth" without SSL think there is inherent security, if
> someone has access to the network it is trivial to sniff network traffic
> and pickup the username/password (as noted in the caveats section
> ).
> There is a little more overhead for setting up SSL connections but as long
> as there is keep-alives it's not too big of a penalty. Another option could
> be using two-way SSL for authentication purposes.
>
> -Steve
>
> On Fri, Jan 20, 2017 at 1:00 AM, Byunghoon Lim 
> wrote:
>
>> Hi Ishan! Thanks for the advice :) I will try it.
>>
>> Best,
>> Hoon
>>
>> Regards,
>> Hoon
>>
>> On Fri, Jan 20, 2017 at 11:55 AM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Basic auth should have the best performance (almost negligible
>>> difference between unsecured and secured). Also, you could try delegation
>>> tokens support.
>>>
>>> On Fri, Jan 20, 2017 at 7:41 AM, Byunghoon Lim 
>>> wrote:
>>>
 Hi! I am Hoon who is running a Solr cluster on production.

 I am considering adding an authentication for Solr Cloud using like
 Basic Authentication plugin. Here, my concern is, if I bring the
 authentication plugin to the cluster, how much latency will increase or
 affected.

 Is there any results or data for the performance?
 or, please let me know the best authentication plugin which doesn't
 affect latency.

 Thanks in advance.

 Best,
 Hoon

>>>
>>>
>>
>


-- 
-
Noble Paul

Re: Lucene/Solr 7

2017-01-24 Thread Michael McCandless 
Early may is exactly what I meant by "a few months".

I guess "few" is a dangerous word!

Mike McCandless

http://blog.mikemccandless.com


On Tue, Jan 24, 2017 at 1:02 PM, Joel Bernstein  wrote:
> I was feeling more comfortable with the early may timeframe.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Tue, Jan 24, 2017 at 12:43 PM, Michael McCandless
>  wrote:
>>
>> +1 to push 7.0 out in a few months...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Tue, Jan 24, 2017 at 11:52 AM, Adrien Grand  wrote:
>> > Hi all,
>> >
>> > We have accumulated some good changes in master, like point support in
>> > Solr
>> > or sparse norms/doc-values in Lucene. I think it would be nice to expose
>> > these new features to our users, so what would you think about starting
>> > to
>> > work on making master ready to be released?
>> >
>> > Since the question about the timeframe will be asked, I think we could
>> > target something like early May 2017, which is a bit more than 3 months
>> > away
>> > from now. What do you think?
>> >
>> > Adrien
>>
>> -
>> 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] [Assigned] (SOLR-10016) SQL should support sorting by random_

2017-01-24 Thread Timothy Potter (JIRA) 

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

Timothy Potter reassigned SOLR-10016:
-

Assignee: Timothy Potter

> SQL should support sorting by random_
> ---
>
> Key: SOLR-10016
> URL: https://issues.apache.org/jira/browse/SOLR-10016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>
> I tried using the handy sort=random_ feature in normal queries with SQL 
> and it failed:
> {code} 
> curl --data-urlencode "stmt=select rating, movie_id, user_id from ratings 
> order by random_5150 asc" \
> >  "http://localhost:8983/solr/ratings/sql;
> {"result-set":{"docs":[
> {"EXCEPTION":"Fields in the sort spec must be included in the field 
> list:random_5150","EOF":true}]}}
> {code}
> I'd like to take a stab at fixing this if there are no objections to me doing 
> so?



--
This message was sent by Atlassian JIRA
(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-10016) SQL should support sorting by random_

2017-01-24 Thread Timothy Potter (JIRA) 

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

Timothy Potter commented on SOLR-10016:
---

thanks Joel, will get started on this using the Calcite SQL implementation 

also, Hossman was thinking we should try to solve this by allowing any function 
/ ValueSource (not just random) for sorting SQL results, so I'm going to go 
down that path first


> SQL should support sorting by random_
> ---
>
> Key: SOLR-10016
> URL: https://issues.apache.org/jira/browse/SOLR-10016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>
> I tried using the handy sort=random_ feature in normal queries with SQL 
> and it failed:
> {code} 
> curl --data-urlencode "stmt=select rating, movie_id, user_id from ratings 
> order by random_5150 asc" \
> >  "http://localhost:8983/solr/ratings/sql;
> {"result-set":{"docs":[
> {"EXCEPTION":"Fields in the sort spec must be included in the field 
> list:random_5150","EOF":true}]}}
> {code}
> I'd like to take a stab at fixing this if there are no objections to me doing 
> so?



--
This message was sent by Atlassian 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: Lucene/Solr 7

2017-01-24 Thread Tommaso Teofili 
+1 to Adrien's proposal.

Tommaso

Il giorno mar 24 gen 2017 alle ore 17:52 Adrien Grand 
ha scritto:

> Hi all,
>
> We have accumulated some good changes in master, like point support in
> Solr or sparse norms/doc-values in Lucene. I think it would be nice to
> expose these new features to our users, so what would you think about
> starting to work on making master ready to be released?
>
> Since the question about the timeframe will be asked, I think we could
> target something like early May 2017, which is a bit more than 3 months
> away from now. What do you think?
>
> Adrien
>

Re: Lucene/Solr 7

2017-01-24 Thread Joel Bernstein 
I was feeling more comfortable with the early may timeframe.

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, Jan 24, 2017 at 12:43 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1 to push 7.0 out in a few months...
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Jan 24, 2017 at 11:52 AM, Adrien Grand  wrote:
> > Hi all,
> >
> > We have accumulated some good changes in master, like point support in
> Solr
> > or sparse norms/doc-values in Lucene. I think it would be nice to expose
> > these new features to our users, so what would you think about starting
> to
> > work on making master ready to be released?
> >
> > Since the question about the timeframe will be asked, I think we could
> > target something like early May 2017, which is a bit more than 3 months
> away
> > from now. What do you think?
> >
> > Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 7

2017-01-24 Thread Michael McCandless 
+1 to push 7.0 out in a few months...

Mike McCandless

http://blog.mikemccandless.com


On Tue, Jan 24, 2017 at 11:52 AM, Adrien Grand  wrote:
> Hi all,
>
> We have accumulated some good changes in master, like point support in Solr
> or sparse norms/doc-values in Lucene. I think it would be nice to expose
> these new features to our users, so what would you think about starting to
> work on making master ready to be released?
>
> Since the question about the timeframe will be asked, I think we could
> target something like early May 2017, which is a bit more than 3 months away
> from now. What do you think?
>
> Adrien

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

Re: Lucene/Solr 7

2017-01-24 Thread Joel Bernstein 
+1

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, Jan 24, 2017 at 12:16 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I would love to see SOLR-5944, SOLR-8029, SOLR-9835 in a 7.0 release. I
> think all of these are very close to landing up on master.
>
> On Tue, Jan 24, 2017 at 10:22 PM, Adrien Grand  wrote:
>
>> Hi all,
>>
>> We have accumulated some good changes in master, like point support in
>> Solr or sparse norms/doc-values in Lucene. I think it would be nice to
>> expose these new features to our users, so what would you think about
>> starting to work on making master ready to be released?
>>
>> Since the question about the timeframe will be asked, I think we could
>> target something like early May 2017, which is a bit more than 3 months
>> away from now. What do you think?
>>
>> Adrien
>>
>
>

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3795/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at https://127.0.0.1:64100/solr/awhollynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 510HTTP ERROR: 510 Problem 
accessing /solr/awhollynewcollection_0/select. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:4},code=510}
 http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028   

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


Error 510 


HTTP ERROR: 510
Problem accessing /solr/awhollynewcollection_0/select. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:4},code=510}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([C8AE32E10101EF03:80DB46550732C096]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:595)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:439)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:391)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1198)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1198)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1198)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1198)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1198)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:517)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at

Re: Lucene/Solr 7

2017-01-24 Thread Ishan Chattopadhyaya 
I would love to see SOLR-5944, SOLR-8029, SOLR-9835 in a 7.0 release. I
think all of these are very close to landing up on master.

On Tue, Jan 24, 2017 at 10:22 PM, Adrien Grand  wrote:

> Hi all,
>
> We have accumulated some good changes in master, like point support in
> Solr or sparse norms/doc-values in Lucene. I think it would be nice to
> expose these new features to our users, so what would you think about
> starting to work on making master ready to be released?
>
> Since the question about the timeframe will be asked, I think we could
> target something like early May 2017, which is a bit more than 3 months
> away from now. What do you think?
>
> Adrien
>

Re: Inquiry for Solr Cloud Authentication

2017-01-24 Thread Steve Davids 
Don't let "basic auth" without SSL think there is inherent security, if
someone has access to the network it is trivial to sniff network traffic
and pickup the username/password (as noted in the caveats section
).
There is a little more overhead for setting up SSL connections but as long
as there is keep-alives it's not too big of a penalty. Another option could
be using two-way SSL for authentication purposes.

-Steve

On Fri, Jan 20, 2017 at 1:00 AM, Byunghoon Lim  wrote:

> Hi Ishan! Thanks for the advice :) I will try it.
>
> Best,
> Hoon
>
> Regards,
> Hoon
>
> On Fri, Jan 20, 2017 at 11:55 AM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Basic auth should have the best performance (almost negligible difference
>> between unsecured and secured). Also, you could try delegation tokens
>> support.
>>
>> On Fri, Jan 20, 2017 at 7:41 AM, Byunghoon Lim 
>> wrote:
>>
>>> Hi! I am Hoon who is running a Solr cluster on production.
>>>
>>> I am considering adding an authentication for Solr Cloud using like
>>> Basic Authentication plugin. Here, my concern is, if I bring the
>>> authentication plugin to the cluster, how much latency will increase or
>>> affected.
>>>
>>> Is there any results or data for the performance?
>>> or, please let me know the best authentication plugin which doesn't
>>> affect latency.
>>>
>>> Thanks in advance.
>>>
>>> Best,
>>> Hoon
>>>
>>
>>
>

Lucene/Solr 7

2017-01-24 Thread Adrien Grand 
Hi all,

We have accumulated some good changes in master, like point support in Solr
or sparse norms/doc-values in Lucene. I think it would be nice to expose
these new features to our users, so what would you think about starting to
work on making master ready to be released?

Since the question about the timeframe will be asked, I think we could
target something like early May 2017, which is a bit more than 3 months
away from now. What do you think?

Adrien

Re: Test passes, build fails with "Could not remove temporary path"

2017-01-24 Thread Uwe Schindler 
Hi,

The problem is also the security manager and it's policy file. This is why we 
have the temp dir in current folder. As there is no easy way to have an 
absolute path in the policy file, we have it like this. Another way would be to 
pass a sys prop for the temp directory and add a policy file rule.

Uwe

Am 24. Januar 2017 12:06:12 MEZ schrieb Dawid Weiss :
>It's exactly that, actually. We place java.io.tmpdir under ./, so this
>directory always remains after the tests are done. I filed this issue:
>
>https://github.com/randomizedtesting/randomizedtesting/issues/247
>
>But I honestly don't know what the "right" way to fix it is. The
>runner assumes cwd should be left clean -- perhaps this should be a
>switch too (with similar wipe|ignore|warn options, defaulting to warn
>for backcompat).
>
>Note that LuceneTestCase already has leftover file detection facility
>it manages internally anyway (TestRuleTemporaryFilesCleanup).
>
>Dawid
>
>On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss 
>wrote:
>> No problem at all. I wonder if we (in Lucene) don't point the temp
>> folder under cwd -- we probably do... If so then this is something I
>> didn't give much thought to... special case which should probably be
>> allowed. Check common-build and confirm if this is the case.
>>
>> Dawid
>>
>> On Mon, Jan 23, 2017 at 3:41 PM, David Smiley
> wrote:
>>> Thanks very much Dawid.  So indeed, the directory in question isn't
>quite
>>> empty; it contains a "temp" directory (that is empty).  Off to the
>next
>>> thing to debug
>>>
>>> Thanks again.
>>> ~ David
>>>
>>> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss 
>wrote:

 I've committed LUCENE-7653 which should help you diagnose the
>problem,
 David. First, it'll clean the cwd of a forked process before the
>tests
 start (something that wasn't done before). Second, it'll report
>what
 files remained uncleaned after a run.

 Hope it'll help.

 Dawid

 On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss
>
 wrote:
 > Hi David!
 >
 >> I can't find the string "Could not remove temporary path" in our
 >> codebase;
 >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how
>to
 >> debug
 >> this... maybe Solr wasn't closed properly?  Although this
>doesn't
 >> happen
 >
 > Yes, this message has a source in ANT's unit test runner code,
>here:
 >
 >
 >
>https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
 >
 > Specifically, it couldn't delete the temporary folder -- most
>likely
 > it wasn't empty (there were some files inside the folder). I
>think the
 > message here should be improved -- I'll do that -- but in the
>mean
 > time make sure the test's folder is empty; if it isn't, the build
>will
 > fail.
 >
 > Dawid
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>For additional commands, e-mail: dev-h...@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Test passes, build fails with "Could not remove temporary path"

2017-01-24 Thread David Smiley 
Check this out: (FYI this is my test; doesn't exist upstream yet):

> ant test -Dtestcase=HeatmapSpatialFieldTest
BUILD SUCCESSFUL, 1 minute 40 seconds
> ant test-core -Dtestcase=HeatmapSpatialFieldTest
BUILD FAILED, 25 seconds





So it turns out the "-init-totals" task sets up the temp dir along with a
deleteonexit.

Just to verify, I temporarily modified test-core to first invoke
"-init-totals", and it passed!  Perhaps all the test-* tasks should
simply have an "-init-totals" and "-check-totals" then?

~ David


On Tue, Jan 24, 2017 at 6:06 AM Dawid Weiss  wrote:

> It's exactly that, actually. We place java.io.tmpdir under ./, so this
> directory always remains after the tests are done. I filed this issue:
>
> https://github.com/randomizedtesting/randomizedtesting/issues/247
>
> But I honestly don't know what the "right" way to fix it is. The
> runner assumes cwd should be left clean -- perhaps this should be a
> switch too (with similar wipe|ignore|warn options, defaulting to warn
> for backcompat).
>
> Note that LuceneTestCase already has leftover file detection facility
> it manages internally anyway (TestRuleTemporaryFilesCleanup).
>
> Dawid
>
> On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss 
> wrote:
> > No problem at all. I wonder if we (in Lucene) don't point the temp
> > folder under cwd -- we probably do... If so then this is something I
> > didn't give much thought to... special case which should probably be
> > allowed. Check common-build and confirm if this is the case.
> >
> > Dawid
> >
> > On Mon, Jan 23, 2017 at 3:41 PM, David Smiley 
> wrote:
> >> Thanks very much Dawid.  So indeed, the directory in question isn't
> quite
> >> empty; it contains a "temp" directory (that is empty).  Off to the next
> >> thing to debug
> >>
> >> Thanks again.
> >> ~ David
> >>
> >> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss 
> wrote:
> >>>
> >>> I've committed LUCENE-7653 which should help you diagnose the problem,
> >>> David. First, it'll clean the cwd of a forked process before the tests
> >>> start (something that wasn't done before). Second, it'll report what
> >>> files remained uncleaned after a run.
> >>>
> >>> Hope it'll help.
> >>>
> >>> Dawid
> >>>
> >>> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
> >>> wrote:
> >>> > Hi David!
> >>> >
> >>> >> I can't find the string "Could not remove temporary path" in our
> >>> >> codebase;
> >>> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to
> >>> >> debug
> >>> >> this... maybe Solr wasn't closed properly?  Although this doesn't
> >>> >> happen
> >>> >
> >>> > Yes, this message has a source in ANT's unit test runner code, here:
> >>> >
> >>> >
> >>> >
> https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
> >>> >
> >>> > Specifically, it couldn't delete the temporary folder -- most likely
> >>> > it wasn't empty (there were some files inside the folder). I think
> the
> >>> > message here should be improved -- I'll do that -- but in the mean
> >>> > time make sure the test's folder is empty; if it isn't, the build
> will
> >>> > fail.
> >>> >
> >>> > Dawid
> >>
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> http://www.solrenterprisesearchserver.com
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[GitHub] lucene-solr pull request #66: SOLR-8146: Allowing SolrJ CloudSolrClient to h...

2017-01-24 Thread susheelks 
Github user susheelks closed the pull request at:

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


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

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

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6368/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest

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

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<5>
at 
__randomizedtesting.SeedInfo.seed([1BF855745BF581:74EB1910307FB20E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest(TestCloudRecovery.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12393 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestCloudRecovery

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/631/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=14805, name=jetty-launcher-2141-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=14793, name=jetty-launcher-2141-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=14805, name=jetty-launcher-2141-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at

Re: Test passes, build fails with "Could not remove temporary path"

2017-01-24 Thread Dawid Weiss 
It's exactly that, actually. We place java.io.tmpdir under ./, so this
directory always remains after the tests are done. I filed this issue:

https://github.com/randomizedtesting/randomizedtesting/issues/247

But I honestly don't know what the "right" way to fix it is. The
runner assumes cwd should be left clean -- perhaps this should be a
switch too (with similar wipe|ignore|warn options, defaulting to warn
for backcompat).

Note that LuceneTestCase already has leftover file detection facility
it manages internally anyway (TestRuleTemporaryFilesCleanup).

Dawid

On Mon, Jan 23, 2017 at 7:22 PM, Dawid Weiss  wrote:
> No problem at all. I wonder if we (in Lucene) don't point the temp
> folder under cwd -- we probably do... If so then this is something I
> didn't give much thought to... special case which should probably be
> allowed. Check common-build and confirm if this is the case.
>
> Dawid
>
> On Mon, Jan 23, 2017 at 3:41 PM, David Smiley  
> wrote:
>> Thanks very much Dawid.  So indeed, the directory in question isn't quite
>> empty; it contains a "temp" directory (that is empty).  Off to the next
>> thing to debug
>>
>> Thanks again.
>> ~ David
>>
>> On Mon, Jan 23, 2017 at 7:40 AM Dawid Weiss  wrote:
>>>
>>> I've committed LUCENE-7653 which should help you diagnose the problem,
>>> David. First, it'll clean the cwd of a forked process before the tests
>>> start (something that wasn't done before). Second, it'll report what
>>> files remained uncleaned after a run.
>>>
>>> Hope it'll help.
>>>
>>> Dawid
>>>
>>> On Fri, Jan 20, 2017 at 8:57 AM, Dawid Weiss 
>>> wrote:
>>> > Hi David!
>>> >
>>> >> I can't find the string "Could not remove temporary path" in our
>>> >> codebase;
>>> >> maybe it's in randomized-testing?  (CC Dawid)  I'm not sure how to
>>> >> debug
>>> >> this... maybe Solr wasn't closed properly?  Although this doesn't
>>> >> happen
>>> >
>>> > Yes, this message has a source in ANT's unit test runner code, here:
>>> >
>>> >
>>> > https://github.com/randomizedtesting/randomizedtesting/blob/master/junit4-ant/src/main/java/com/carrotsearch/ant/tasks/junit4/JUnit4.java#L1031-L1041
>>> >
>>> > Specifically, it couldn't delete the temporary folder -- most likely
>>> > it wasn't empty (there were some files inside the folder). I think the
>>> > message here should be improved -- I'll do that -- but in the mean
>>> > time make sure the test's folder is empty; if it isn't, the build will
>>> > fail.
>>> >
>>> > Dawid
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1221 - Failure

2017-01-24 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1221/

6 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([B7E3636E8B9953D9:153B2DB4EF6B7ADF]:0)
at java.lang.Float.valueOf(Float.java:433)
at 
org.apache.lucene.search.FieldComparator$FloatComparator.value(FieldComparator.java:275)
at 
org.apache.lucene.search.FieldComparator$FloatComparator.value(FieldComparator.java:226)
at 
org.apache.lucene.search.FieldValueHitQueue.fillFields(FieldValueHitQueue.java:208)
at 
org.apache.lucene.search.TopFieldCollector.populateResults(TopFieldCollector.java:535)
at 
org.apache.lucene.search.TopDocsCollector.topDocs(TopDocsCollector.java:156)
at 
org.apache.lucene.search.TopDocsCollector.topDocs(TopDocsCollector.java:93)
at 
org.apache.lucene.search.TopFieldCollector.topDocs(TopFieldCollector.java:559)
at 
org.apache.lucene.index.TestIndexSorting.testRandom3(TestIndexSorting.java:2345)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)


FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard2

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard2
at 
__randomizedtesting.SeedInfo.seed([2D5700C2A2851D2E:FFA74C21FC2ABB1C]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:795)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange(CdcrReplicationDistributedZkTest.java:306)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at

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

2017-01-24 Thread Policeman Jenkins Server 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1094/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([836C439A06BD0838:62EA2A641B8BEED1]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:416)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1344)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1095)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1037)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.create1ShardCollection(TestSolrCloudWithSecureImpersonation.java:189)
at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation.testForwarding(TestSolrCloudWithSecureImpersonation.java:346)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at