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

[Policeman Jenkins Server]

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

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=12150, name=jetty-launcher-1841-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=12150, name=jetty-launcher-1841-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([F7480CDAA9E79A11]:0)




Build Log:
[...truncated 11303 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/J1/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_F7480CDAA9E79A11-001/init-core-data-001
   [junit4]   2> 873008 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[F7480CDAA9E79A11]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 873042 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[F7480CDAA9E79A11]-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/J1/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_F7480CDAA9E79A11-001/tempDir-001
   [junit4]   2> 873042 INFO  

Nightly Builds wiki page sadly out of date

[Erick Erickson]

https://wiki.apache.org/solr/NightlyBuilds

The "trunk" version is 5x! Where should we be pointing this now? Or
should we delete it? I've marked it as Obsolete while we decide.

Erick

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

Re: PeerSyncReplicationTest failure

[Erick Erickson]

Pushkar:

Yes, PeerSynchReplicationTest. I'm getting 21/100  failures when
beasting on 6x so it's not a trunk-only issue. The script I was using
is Mark Miller's "The best Lucene / Solr beasting script in the world.
TM." here: https://gist.github.com/markrmiller/dbdb792216dc98b018ad

Here's the link to the build:
https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3781/

The "Console output" link won't display much, but the "Skipping 10,574
KB.. Full Log" link should lead you to the full output.

My only real concern here is to determine whether this is an
underlying problem or a test issue for the 6.4 release.

Thanks!
Erick

On Sun, Jan 15, 2017 at 6:26 PM, Pushkar Raste  wrote:
> Erick,
> Is this PeerSyncTest or PeerSyncReplicationTest?
>
> Can you send me link to Jenkins build logs(if this is happening on
> Jenkins).
>
> I recently sent a patch to improve the validation check (in the
> PeerSyncReplicationTest) made in order to figure out if node successfully
> recovered via PeerSync. Not sure if change was made only to the trunk or if
> was applied to 6.X branch as well.
>
>
> On Jan 15, 2017 4:12 PM, "Erick Erickson"  wrote:
>>
>> I was wondering about the failures and tried to beast it on my Pro on
>> trunk which fails first time, every time with a NoSuchMethodError in
>> Lucene, see below.
>>
>> I was wondering whether it would be a bad idea to release 6.4 with the
>> PeerSynch Test failure that shows up but didn't really look whether it
>> was trunk or 6x. Of course if this is only on trunk then it's
>> irrelevant for 6x.
>>
>> Beasting 6x now.
>>
>> 2> 206460 ERROR (coreCloseExecutor-64-thread-1)
>> [n:127.0.0.1:51661_mx_ni c:collection1 s:shard1 r:core_node1
>> x:collection1] o.a.s.u.DirectUpdateHandler2 Error in final commit
>>[junit4]   2> java.lang.NoSuchMethodError:
>>
>> org.apache.lucene.util.packed.DirectWriter.getInstance(Lorg/apache/lucene/store/IndexOutput;JI)Lorg/apache/lucene/util/packed/DirectWriter;
>>[junit4]   2> at
>>
>> org.apache.lucene.util.packed.DirectMonotonicWriter.flush(DirectMonotonicWriter.java:91)
>>[junit4]   2> at
>>
>> org.apache.lucene.util.packed.DirectMonotonicWriter.finish(DirectMonotonicWriter.java:127)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addTermsDict(Lucene70DocValuesConsumer.java:478)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.doAddSortedField(Lucene70DocValuesConsumer.java:437)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addSortedSetField(Lucene70DocValuesConsumer.java:571)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:129)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.SortedSetDocValuesWriter.flush(SortedSetDocValuesWriter.java:221)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:248)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:132)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:444)
>>[junit4]   2> at
>> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:539)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:653)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3001)
>>[junit4]   2> at
>> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3211)
>>[junit4]   2> at
>> org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:792)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DefaultSolrCoreState.closeIndexWriter(DefaultSolrCoreState.java:88)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DefaultSolrCoreState.close(DefaultSolrCoreState.java:379)
>>
>> -
>> 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

Re: 6.4 release

[David Smiley]

Hello Uwe,

On Sat, Jan 14, 2017 at 1:56 PM Uwe Schindler  wrote:

> Hi,
>
>
>
> I fixed the compile warning. The more serious issue was a problem with
> Solr and Eclipse: It did not compile anymore, because the Solr UHighlighter
> implementation was using a Java-1.0-like inner class which was not nested
> but just top-level in same source file.
>

Can you please clarify what this problem is?  I thought I knew but your
example doesn't match my understanding.  I don't use Eclipse so it's not
apparent to me.  UnifiedSolrHighlighter has a static inner class
SolrExtendedUnifiedHighlighter.  It is an inner class; not some other class
in the same source file.  UnifiedHighlither (in Lucene) only has inner
classes too.  Maybe you meant the class FragmentQueue in Lucene
Highlighter.java?  I dunno.


> IMHO, we should add a style check in “ant validate” to prevent this type
> of class declaration. Top-Level classes should always be in separate files
> or properly nested.
>

+1

~ David
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Updated] (SOLR-9969) Display new metrics on the UI

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-9969:

Attachment: mbeans_handler.png

For example , here is a screenshot of what happens when we click on one of them

> Display new metrics on the UI
> -
>
> Key: SOLR-9969
> URL: https://issues.apache.org/jira/browse/SOLR-9969
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Varun Thacker
> Attachments: mbeans_handler.png
>
>
> The current Core Selector -> Core -> Plugin/Stats UI shows tabs for the new 
> metrics information we are adding but doesn't populate correctly.



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

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

[jira] [Created] (SOLR-9969) Display new metrics on the UI

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-9969:
---

 Summary: Display new metrics on the UI
 Key: SOLR-9969
 URL: https://issues.apache.org/jira/browse/SOLR-9969
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: metrics
Reporter: Varun Thacker


The current Core Selector -> Core -> Plugin/Stats UI shows tabs for the new 
metrics information we are adding but doesn't populate correctly.



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

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

[jira] [Closed] (LUCENE-7634) is there a Lucene that can be used on Android devices

[huawei_xu (JIRA)]

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

huawei_xu closed LUCENE-7634.
-

> is there a Lucene that can be used on Android devices
> -
>
> Key: LUCENE-7634
> URL: https://issues.apache.org/jira/browse/LUCENE-7634
> Project: Lucene - Core
>  Issue Type: New Feature
> Environment: Android
>Reporter: huawei_xu
>Priority: Minor
>
> we are implement lucene on Android devices, and currently we have some issues 
> on compileing lucene under Android enviroument, So we are wondering Lucene 
> will release a version that can follow latest version based on Android 
> enviroument?



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

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

[jira] [Commented] (LUCENE-7634) is there a Lucene that can be used on Android devices

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on LUCENE-7634:
---

https://lucene.apache.org/core/discussion.html#developer-discussion-devluceneapacheorg

> is there a Lucene that can be used on Android devices
> -
>
> Key: LUCENE-7634
> URL: https://issues.apache.org/jira/browse/LUCENE-7634
> Project: Lucene - Core
>  Issue Type: New Feature
> Environment: Android
>Reporter: huawei_xu
>Priority: Minor
>
> we are implement lucene on Android devices, and currently we have some issues 
> on compileing lucene under Android enviroument, So we are wondering Lucene 
> will release a version that can follow latest version based on Android 
> enviroument?



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

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

[jira] [Commented] (LUCENE-7634) is there a Lucene that can be used on Android devices

[huawei_xu (JIRA)]

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

huawei_xu commented on LUCENE-7634:
---

thanks for your answer, could you give me an link to mailing list? i cant find 
it anywhere.

> is there a Lucene that can be used on Android devices
> -
>
> Key: LUCENE-7634
> URL: https://issues.apache.org/jira/browse/LUCENE-7634
> Project: Lucene - Core
>  Issue Type: New Feature
> Environment: Android
>Reporter: huawei_xu
>Priority: Minor
>
> we are implement lucene on Android devices, and currently we have some issues 
> on compileing lucene under Android enviroument, So we are wondering Lucene 
> will release a version that can follow latest version based on Android 
> enviroument?



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

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

[jira] [Resolved] (LUCENE-7634) is there a Lucene that can be used on Android devices

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch resolved LUCENE-7634.
---
Resolution: Pending Closed

> is there a Lucene that can be used on Android devices
> -
>
> Key: LUCENE-7634
> URL: https://issues.apache.org/jira/browse/LUCENE-7634
> Project: Lucene - Core
>  Issue Type: New Feature
> Environment: Android
>Reporter: huawei_xu
>Priority: Minor
>
> we are implement lucene on Android devices, and currently we have some issues 
> on compileing lucene under Android enviroument, So we are wondering Lucene 
> will release a version that can follow latest version based on Android 
> enviroument?



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

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

[jira] [Commented] (LUCENE-7634) is there a Lucene that can be used on Android devices

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on LUCENE-7634:
---

This is not the best place to ask this question. You want to ask that on 
lucene-dev mailing list. This one is used to report issues/request specific 
features against the source code.

I suspect the answer will be 'no', but you will get a much better depth of 
discussion on the mailing list.

> is there a Lucene that can be used on Android devices
> -
>
> Key: LUCENE-7634
> URL: https://issues.apache.org/jira/browse/LUCENE-7634
> Project: Lucene - Core
>  Issue Type: New Feature
> Environment: Android
>Reporter: huawei_xu
>Priority: Minor
>
> we are implement lucene on Android devices, and currently we have some issues 
> on compileing lucene under Android enviroument, So we are wondering Lucene 
> will release a version that can follow latest version based on Android 
> enviroument?



--
This message was sent by Atlassian 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: PeerSyncReplicationTest failure

[Erick Erickson]

Thanks Uwe, I didn't _think_ what I was seeing was possible.

I was using Mark's beast script with the option set that's supposed to
do a clean-and-compie first when I saw that error, so I don't quite
know what was up with that.

But with a manual clean that error went away so I'm on to others.

Erick

On Sun, Jan 15, 2017 at 2:14 PM, Uwe Schindler  wrote:
> Hi,
>
> Are you sure that you ran ant clean on top level? It is impossible that this
> error occurs if compilation was fine.
>
> Uwe
>
> Am 15. Januar 2017 22:10:27 MEZ schrieb Erick Erickson
> :
>>
>> I was wondering about the failures and tried to beast it on my Pro on
>> trunk which fails first time, every time with a NoSuchMethodError in
>> Lucene, see below.
>>
>> I was wondering whether it would be a bad idea to release 6.4 with the
>> PeerSynch Test failure that shows up but didn't really look whether it
>> was trunk or 6x. Of course if this is only on trunk then it's
>> irrelevant for 6x.
>>
>> Beasting 6x now.
>>
>> 2> 206460 ERROR (coreCloseExecutor-64-thread-1)
>> [n:127.0.0.1:51661_mx_ni c:collection1 s:shard1 r:core_node1
>> x:collection1] o.a.s.u.DirectUpdateHandler2 Error in final commit
>>[junit4]   2> java.lang.NoSuchMethodError:
>>
>> org.apache.lucene.util.packed.DirectWriter.getInstance(Lorg/apache/lucene/store/IndexOutput;JI)Lorg/apache/lucene/util/packed/DirectWriter;
>>[junit4]   2> at
>>
>> org.apache.lucene.util.packed.DirectMonotonicWriter.flush(DirectMonotonicWriter.java:91)
>>[junit4]   2> at
>>
>> org.apache.lucene.util.packed.DirectMonotonicWriter.finish(DirectMonotonicWriter.java:127)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addTermsDict(Lucene70DocValuesConsumer.java:478)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.doAddSortedField(Lucene70DocValuesConsumer.java:437)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addSortedSetField(Lucene70DocValuesConsumer.java:571)
>>[junit4]   2> at
>>
>> org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:129)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.SortedSetDocValuesWriter.flush(SortedSetDocValuesWriter.java:221)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:248)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:132)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:444)
>>[junit4]   2> at
>> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:539)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:653)
>>[junit4]   2> at
>>
>> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3001)
>>[junit4]   2> at
>> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3211)
>>[junit4]   2> at
>> org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:792)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DefaultSolrCoreState.closeIndexWriter(DefaultSolrCoreState.java:88)
>>[junit4]   2> at
>>
>> org.apache.solr.update.DefaultSolrCoreState.close(DefaultSolrCoreState.java:379)
>>
>> 
>>
>> 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

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

[jira] [Created] (LUCENE-7634) is there a Lucene that can be used on Android devices

[huawei_xu (JIRA)]

huawei_xu created LUCENE-7634:
-

 Summary: is there a Lucene that can be used on Android devices
 Key: LUCENE-7634
 URL: https://issues.apache.org/jira/browse/LUCENE-7634
 Project: Lucene - Core
  Issue Type: New Feature
 Environment: Android
Reporter: huawei_xu
Priority: Minor


we are implement lucene on Android devices, and currently we have some issues 
on compileing lucene under Android enviroument, So we are wondering Lucene will 
release a version that can follow latest version based on Android enviroument?





--
This message was sent by Atlassian 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: PeerSyncReplicationTest failure

[Pushkar Raste]

Erick,
Is this PeerSyncTest or PeerSyncReplicationTest?

Can you send me link to Jenkins build logs(if this is happening on
Jenkins).

I recently sent a patch to improve the validation check (in the
PeerSyncReplicationTest) made in order to figure out if node successfully
recovered via PeerSync. Not sure if change was made only to the trunk or if
was applied to 6.X branch as well.

On Jan 15, 2017 4:12 PM, "Erick Erickson"  wrote:

> I was wondering about the failures and tried to beast it on my Pro on
> trunk which fails first time, every time with a NoSuchMethodError in
> Lucene, see below.
>
> I was wondering whether it would be a bad idea to release 6.4 with the
> PeerSynch Test failure that shows up but didn't really look whether it
> was trunk or 6x. Of course if this is only on trunk then it's
> irrelevant for 6x.
>
> Beasting 6x now.
>
> 2> 206460 ERROR (coreCloseExecutor-64-thread-1)
> [n:127.0.0.1:51661_mx_ni c:collection1 s:shard1 r:core_node1
> x:collection1] o.a.s.u.DirectUpdateHandler2 Error in final commit
>[junit4]   2> java.lang.NoSuchMethodError:
> org.apache.lucene.util.packed.DirectWriter.getInstance(Lorg/
> apache/lucene/store/IndexOutput;JI)Lorg/apache/lucene/util/packed/
> DirectWriter;
>[junit4]   2> at
> org.apache.lucene.util.packed.DirectMonotonicWriter.flush(
> DirectMonotonicWriter.java:91)
>[junit4]   2> at
> org.apache.lucene.util.packed.DirectMonotonicWriter.finish(
> DirectMonotonicWriter.java:127)
>[junit4]   2> at
> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addTermsDict(
> Lucene70DocValuesConsumer.java:478)
>[junit4]   2> at
> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.
> doAddSortedField(Lucene70DocValuesConsumer.java:437)
>[junit4]   2> at
> org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.
> addSortedSetField(Lucene70DocValuesConsumer.java:571)
>[junit4]   2> at
> org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.
> addSortedSetField(PerFieldDocValuesFormat.java:129)
>[junit4]   2> at
> org.apache.lucene.index.SortedSetDocValuesWriter.flush(
> SortedSetDocValuesWriter.java:221)
>[junit4]   2> at
> org.apache.lucene.index.DefaultIndexingChain.writeDocValues(
> DefaultIndexingChain.java:248)
>[junit4]   2> at
> org.apache.lucene.index.DefaultIndexingChain.flush(
> DefaultIndexingChain.java:132)
>[junit4]   2> at
> org.apache.lucene.index.DocumentsWriterPerThread.flush(
> DocumentsWriterPerThread.java:444)
>[junit4]   2> at
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:539)
>[junit4]   2> at
> org.apache.lucene.index.DocumentsWriter.flushAllThreads(
> DocumentsWriter.java:653)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(
> IndexWriter.java:3001)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3211)
>[junit4]   2> at
> org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174)
>[junit4]   2> at
> org.apache.solr.update.DirectUpdateHandler2.closeWriter(
> DirectUpdateHandler2.java:792)
>[junit4]   2> at
> org.apache.solr.update.DefaultSolrCoreState.closeIndexWriter(
> DefaultSolrCoreState.java:88)
>[junit4]   2> at
> org.apache.solr.update.DefaultSolrCoreState.close(
> DefaultSolrCoreState.java:379)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Resolved] (SOLR-3491) PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-3491.

   Resolution: Not A Problem
Fix Version/s: (was: 6.0)
   (was: 4.9)

Looks like this was fixed by SOLR-5496?

Either way, i'm not seeing anything that looks like what i described in the 
issue description in these classes on master now.

> PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close
> 
>
> Key: SOLR-3491
> URL: https://issues.apache.org/jira/browse/SOLR-3491
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>
> Discovered while making sense of SOLR-3423...
> * PeerSync & SyncStrategy each use their own private instance of 
> HttpShardHandlerFactory, which are never close()ed (so the threadpool is 
> never closed)
> * should these classes be using the ShardHandler configured on the SolrCore



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 682 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:57542/collection1]> but was:http://127.0.0.1:35046/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:57542/collection1]> but 
was:http://127.0.0.1:35046/collection1]>
at 
__randomizedtesting.SeedInfo.seed([3301F02D39FC3BA8:BB55CFF797005650]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3781/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:64262/lq_fx/collection1]> but was:http://127.0.0.1:64258/lq_fx/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:64262/lq_fx/collection1]> but 
was:http://127.0.0.1:64258/lq_fx/collection1]>
at 
__randomizedtesting.SeedInfo.seed([66390243AC03ACF0:EE6D3D9902FFC108]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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)
  

[jira] [Commented] (SOLR-9303) Refactor CloudSolrClient for extensibility

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9303:
--

Github user paulo-raca commented on the issue:

https://github.com/apache/lucene-solr/pull/51
  
Nobody cares, closing it


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



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

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

[jira] [Commented] (SOLR-9303) Refactor CloudSolrClient for extensibility

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9303:
--

Github user paulo-raca closed the pull request at:

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


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



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

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

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

[paulo-raca]

Github user paulo-raca closed the pull request at:

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


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

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

[GitHub] lucene-solr issue #51: SOLR-9303: Refactor CloudSolrClient for extensibility

[paulo-raca]

Github user paulo-raca commented on the issue:

https://github.com/apache/lucene-solr/pull/51
  
Nobody cares, closing it


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

Re: PeerSyncReplicationTest failure

[Uwe Schindler]

Hi,

Are you sure that you ran ant clean on top level? It is impossible that this 
error occurs if compilation was fine.

Uwe

Am 15. Januar 2017 22:10:27 MEZ schrieb Erick Erickson 
:
>I was wondering about the failures and tried to beast it on my Pro on
>trunk which fails first time, every time with a NoSuchMethodError in
>Lucene, see below.
>
>I was wondering whether it would be a bad idea to release 6.4 with the
>PeerSynch Test failure that shows up but didn't really look whether it
>was trunk or 6x. Of course if this is only on trunk then it's
>irrelevant for 6x.
>
>Beasting 6x now.
>
>2> 206460 ERROR (coreCloseExecutor-64-thread-1)
>[n:127.0.0.1:51661_mx_ni c:collection1 s:shard1 r:core_node1
>x:collection1] o.a.s.u.DirectUpdateHandler2 Error in final commit
>   [junit4]   2> java.lang.NoSuchMethodError:
>org.apache.lucene.util.packed.DirectWriter.getInstance(Lorg/apache/lucene/store/IndexOutput;JI)Lorg/apache/lucene/util/packed/DirectWriter;
>   [junit4]   2> at
>org.apache.lucene.util.packed.DirectMonotonicWriter.flush(DirectMonotonicWriter.java:91)
>   [junit4]   2> at
>org.apache.lucene.util.packed.DirectMonotonicWriter.finish(DirectMonotonicWriter.java:127)
>   [junit4]   2> at
>org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addTermsDict(Lucene70DocValuesConsumer.java:478)
>   [junit4]   2> at
>org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.doAddSortedField(Lucene70DocValuesConsumer.java:437)
>   [junit4]   2> at
>org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addSortedSetField(Lucene70DocValuesConsumer.java:571)
>   [junit4]   2> at
>org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:129)
>   [junit4]   2> at
>org.apache.lucene.index.SortedSetDocValuesWriter.flush(SortedSetDocValuesWriter.java:221)
>   [junit4]   2> at
>org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:248)
>   [junit4]   2> at
>org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:132)
>   [junit4]   2> at
>org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:444)
>   [junit4]   2> at
>org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:539)
>   [junit4]   2> at
>org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:653)
>   [junit4]   2> at
>org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3001)
>   [junit4]   2> at
>org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3211)
>   [junit4]   2> at
>org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174)
>   [junit4]   2> at
>org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:792)
>   [junit4]   2> at
>org.apache.solr.update.DefaultSolrCoreState.closeIndexWriter(DefaultSolrCoreState.java:88)
>   [junit4]   2> at
>org.apache.solr.update.DefaultSolrCoreState.close(DefaultSolrCoreState.java:379)
>
>-
>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

PeerSyncReplicationTest failure

[Erick Erickson]

I was wondering about the failures and tried to beast it on my Pro on
trunk which fails first time, every time with a NoSuchMethodError in
Lucene, see below.

I was wondering whether it would be a bad idea to release 6.4 with the
PeerSynch Test failure that shows up but didn't really look whether it
was trunk or 6x. Of course if this is only on trunk then it's
irrelevant for 6x.

Beasting 6x now.

2> 206460 ERROR (coreCloseExecutor-64-thread-1)
[n:127.0.0.1:51661_mx_ni c:collection1 s:shard1 r:core_node1
x:collection1] o.a.s.u.DirectUpdateHandler2 Error in final commit
   [junit4]   2> java.lang.NoSuchMethodError:
org.apache.lucene.util.packed.DirectWriter.getInstance(Lorg/apache/lucene/store/IndexOutput;JI)Lorg/apache/lucene/util/packed/DirectWriter;
   [junit4]   2> at
org.apache.lucene.util.packed.DirectMonotonicWriter.flush(DirectMonotonicWriter.java:91)
   [junit4]   2> at
org.apache.lucene.util.packed.DirectMonotonicWriter.finish(DirectMonotonicWriter.java:127)
   [junit4]   2> at
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addTermsDict(Lucene70DocValuesConsumer.java:478)
   [junit4]   2> at
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.doAddSortedField(Lucene70DocValuesConsumer.java:437)
   [junit4]   2> at
org.apache.lucene.codecs.lucene70.Lucene70DocValuesConsumer.addSortedSetField(Lucene70DocValuesConsumer.java:571)
   [junit4]   2> at
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addSortedSetField(PerFieldDocValuesFormat.java:129)
   [junit4]   2> at
org.apache.lucene.index.SortedSetDocValuesWriter.flush(SortedSetDocValuesWriter.java:221)
   [junit4]   2> at
org.apache.lucene.index.DefaultIndexingChain.writeDocValues(DefaultIndexingChain.java:248)
   [junit4]   2> at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:132)
   [junit4]   2> at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:444)
   [junit4]   2> at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:539)
   [junit4]   2> at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:653)
   [junit4]   2> at
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3001)
   [junit4]   2> at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3211)
   [junit4]   2> at
org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3174)
   [junit4]   2> at
org.apache.solr.update.DirectUpdateHandler2.closeWriter(DirectUpdateHandler2.java:792)
   [junit4]   2> at
org.apache.solr.update.DefaultSolrCoreState.closeIndexWriter(DefaultSolrCoreState.java:88)
   [junit4]   2> at
org.apache.solr.update.DefaultSolrCoreState.close(DefaultSolrCoreState.java:379)

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

[jira] [Commented] (SOLR-3491) PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-3491:
--

[~yo...@apache.org][~hossman_luc...@fucit.org] Can this be closed? It's 
ancient...

> PeerSync & SyncStrategy use an HttpShardHandlerFactory that they never close
> 
>
> Key: SOLR-3491
> URL: https://issues.apache.org/jira/browse/SOLR-3491
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Yonik Seeley
> Fix For: 4.9, 6.0
>
>
> Discovered while making sense of SOLR-3423...
> * PeerSync & SyncStrategy each use their own private instance of 
> HttpShardHandlerFactory, which are never close()ed (so the threadpool is 
> never closed)
> * should these classes be using the ShardHandler configured on the SolrCore



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+152) - Build # 18782 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18782/
Java: 64bit/jdk-9-ea+152 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1014)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:841)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:559)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:195)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:344)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:707)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:924)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:841)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:559)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:195)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:97)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:739)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:924)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:841)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:559)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.MetricsDirectoryFactory.get(MetricsDirectoryFactory.java:195)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:475)  
at org.apache.solr.core.SolrCore.(SolrCore.java:918)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:841)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:559)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 

[JENKINS] Lucene-Solr-6.4-Linux (32bit/jdk1.8.0_112) - Build # 7 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/7/
Java: 32bit/jdk1.8.0_112 -client -XX:+UseSerialGC

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

Error Message:
Error from server at http://127.0.0.1:44200/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:5},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 http://127.0.0.1:44200/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:5},code=510}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([E04745701E27816B:A83231C41814AEFE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:578)
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:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
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:516)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 238 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 41964 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.5.0-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1186.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.tgz...
   [smoker] 65.1 MB in 0.05 sec (1203.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.zip...
   [smoker] 76.0 MB in 0.06 sec (1212.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6208 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6208 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (119.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.5.0-src.tgz...
   [smoker] 40.1 MB in 0.04 sec (1058.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.5.0.tgz...
   [smoker] 140.5 MB in 0.13 sec (1114.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.5.0.zip...
   [smoker] 150.0 MB in 0.13 sec (1134.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.5.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=6233). Happy searching!
   [smoker] 
   [smoker] 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+152) - Build # 2673 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2673/
Java: 32bit/jdk-9-ea+152 -server -XX:+UseSerialGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:41535/collection1]> but was:http://127.0.0.1:34976/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:41535/collection1]> but 
was:http://127.0.0.1:34976/collection1]>
at 
__randomizedtesting.SeedInfo.seed([2E1321E509286F22:A6471E3FA7D402DA]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 
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 

[jira] [Issue Comment Deleted] (SOLR-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9968:
--
Comment: was deleted

(was: Test case)

> Cannot use special characters in Suggester Context Query
> 
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg. 
> {noformat}suggest.cfq=context:c#x{noformat}
>   * Escaping the character makes no difference, eg. 
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is 
> '{{c#x}}'
> 
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new 
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to 
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special 
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} 
> can be used
> * Use the analyzer defined for the context field in the schema



--
This message was sent by Atlassian 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-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9968:
--
Attachment: (was: test_context_query_with_special_characters.patch)

> Cannot use special characters in Suggester Context Query
> 
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg. 
> {noformat}suggest.cfq=context:c#x{noformat}
>   * Escaping the character makes no difference, eg. 
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is 
> '{{c#x}}'
> 
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new 
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to 
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special 
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} 
> can be used
> * Use the analyzer defined for the context field in the schema



--
This message was sent by Atlassian 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-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9968:
--
Attachment: test_context_query_with_special_characters.patch

Test case

> Cannot use special characters in Suggester Context Query
> 
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg. 
> {noformat}suggest.cfq=context:c#x{noformat}
>   * Escaping the character makes no difference, eg. 
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is 
> '{{c#x}}'
> 
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new 
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to 
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special 
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} 
> can be used
> * Use the analyzer defined for the context field in the schema



--
This message was sent by Atlassian 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-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9968:
--
Description: 
h4. Reproduce

1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg. 
{noformat}suggest.cfq=context:c#x{noformat}
  * Escaping the character makes no difference, eg. 
{noformat}suggest.cfq=context:c\#x{noformat}

h4. What happens

The suggestions are not properly filtered

h4. What should happen

The suggestions should be limited to documents where the field {{context}} is 
'{{c#x}}'



What happens is this:

1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new 
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned

Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to 
reproduce this behavior.

So, the question is, how to get the parser and tokenizer to use these special 
characters verbatim? Two ways I can think of:

* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can 
be used
* Use the analyzer defined for the context field in the schema



  was:
h4. Reproduce

1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg. 
{noformat}suggest.cfq=context:c#x{noformat}
  * Escaping the character makes no difference, eg. 
{noformat}suggest.cfq=context:c\#x{noformat}

h4. What happens

The suggestions are not properly filtered

h4. What should happen

The suggestions should be limited to documents where the field {{context}} is 
'{{c#x}}'



What happens is this:

1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new 
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned

So, the question is, how to get the parser and tokenizer to use these special 
characters verbatim? Two ways I can think of:

* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can 
be used
* Use the analyzer defined for the context field in the schema


> Cannot use special characters in Suggester Context Query
> 
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg. 
> {noformat}suggest.cfq=context:c#x{noformat}
>   * Escaping the character makes no difference, eg. 
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is 
> '{{c#x}}'
> 
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new 
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> Attached is an extension to {{SuggestComponentContextFilterQueryTest}} to 
> reproduce this behavior.
> So, the question is, how to get the parser and tokenizer to use these special 
> characters verbatim? Two ways I can think of:
> * Make 

[jira] [Updated] (SOLR-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

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

Georg Sorst updated SOLR-9968:
--
Attachment: test_context_query_with_special_characters.patch

Test case

> Cannot use special characters in Suggester Context Query
> 
>
> Key: SOLR-9968
> URL: https://issues.apache.org/jira/browse/SOLR-9968
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Suggester
>Affects Versions: 6.0, 6.3
>Reporter: Georg Sorst
> Attachments: test_context_query_with_special_characters.patch
>
>
> h4. Reproduce
> 1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
> 2. Add a document containing special characters in that field, eg. '{{c#x}}'
> 3. Use a context query with the Suggester, eg. 
> {noformat}suggest.cfq=context:c#x{noformat}
>   * Escaping the character makes no difference, eg. 
> {noformat}suggest.cfq=context:c\#x{noformat}
> h4. What happens
> The suggestions are not properly filtered
> h4. What should happen
> The suggestions should be limited to documents where the field {{context}} is 
> '{{c#x}}'
> 
> What happens is this:
> 1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
> {{StandardTokenizer}}
> 2. The context query is parsed like this:
> {code:title=SolrSuggester.parseContextFilterQuery}
> query = new 
> StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
> CONTEXTS_FIELD_NAME);
> {code}
> 3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
> the context query into '{{context:c context:x}}'
> 4. This is used for filtering the suggestions
> 5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned
> So, the question is, how to get the parser and tokenizer to use these special 
> characters verbatim? Two ways I can think of:
> * Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} 
> can be used
> * Use the analyzer defined for the context field in the schema



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

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

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

[Policeman Jenkins Server]

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

4 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([90D1FA4B22A09B26:1885C5918C5CF6DE]: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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Created] (SOLR-9968) Cannot use special characters in Suggester Context Query

[Georg Sorst (JIRA)]

Georg Sorst created SOLR-9968:
-

 Summary: Cannot use special characters in Suggester Context Query
 Key: SOLR-9968
 URL: https://issues.apache.org/jira/browse/SOLR-9968
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Suggester
Affects Versions: 6.3, 6.0
Reporter: Georg Sorst


h4. Reproduce

1. Configure the Suggester to use a {{contextField}}, eg. {{context}}
2. Add a document containing special characters in that field, eg. '{{c#x}}'
3. Use a context query with the Suggester, eg. 
{noformat}suggest.cfq=context:c#x{noformat}
  * Escaping the character makes no difference, eg. 
{noformat}suggest.cfq=context:c\#x{noformat}

h4. What happens

The suggestions are not properly filtered

h4. What should happen

The suggestions should be limited to documents where the field {{context}} is 
'{{c#x}}'



What happens is this:

1. {{SolrSuggester.contextFilterQueryAnalyzer}} is hardwired to use 
{{StandardTokenizer}}
2. The context query is parsed like this:
{code:title=SolrSuggester.parseContextFilterQuery}
query = new 
StandardQueryParser(contextFilterQueryAnalyzer).parse(contextFilter, 
CONTEXTS_FIELD_NAME);
{code}
3. The {{StandardQueryParser}} together with {{StandardTokenizer}} will turn 
the context query into '{{context:c context:x}}'
4. This is used for filtering the suggestions
5. Thus, the suggestion where {{context}} is '{{c(x}}' is not returned

So, the question is, how to get the parser and tokenizer to use these special 
characters verbatim? Two ways I can think of:

* Make {{contextFilterQueryAnalyzer}} configurable so {{KeywordTokenizer}} can 
be used
* Use the analyzer defined for the context field in the schema



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 258 - Still Unstable

[Apache Jenkins Server]

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

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

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([964AA14730074046]:0)


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

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

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


FAILED:  org.apache.solr.cloud.hdfs.HdfsWriteToMultipleCollectionsTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([67E596073CD56A74:EFB1A9DD9229078C]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.hdfs.HdfsWriteToMultipleCollectionsTest.test(HdfsWriteToMultipleCollectionsTest.java:137)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Updated] (LUCENE-7623) Add FunctionScoreQuery and FunctionMatchQuery

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-7623:
--
Attachment: LUCENE-7623.patch

I apparently did, yes, sorry... here's the correct patch

> Add FunctionScoreQuery and FunctionMatchQuery
> -
>
> Key: LUCENE-7623
> URL: https://issues.apache.org/jira/browse/LUCENE-7623
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch, 
> LUCENE-7623.patch, LUCENE-7623.patch
>
>
> We should update the various function scoring queries to use the new 
> DoubleValues API



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+152) - Build # 18781 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18781/
Java: 64bit/jdk-9-ea+152 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:44924/collection1]> but was:http://127.0.0.1:46205/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:44924/collection1]> but 
was:http://127.0.0.1:46205/collection1]>
at 
__randomizedtesting.SeedInfo.seed([8CA816869BEE0E4F:4FC295C351263B7]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 
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 

[jira] [Commented] (LUCENE-7632) Add some sugar constructors to TermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7632:
--

Agreed that both changes need to be done at the same time.

> Add some sugar constructors to TermQuery
> 
>
> Key: LUCENE-7632
> URL: https://issues.apache.org/jira/browse/LUCENE-7632
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7632.patch
>
>
> TermQuery should have constructors that take a field and term, in addition to 
> the one taking a Term object.  This has been annoying me for about five years 
> now.



--
This message was sent by Atlassian 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: 6.4 release

[Adrien Grand]

Thanks Alan. Should we do the same with the TermsQuery change since whether
or not it should accept terms from multiple fields is still under
discussion?

JIRA notifications are working well for me.

Le dim. 15 janv. 2017 à 10:38, Alan Woodward  a écrit :

> Sure, I’ll revert it this morning.
>
> As an aside, I don’t seem to be getting email notifications from JIRA
> anymore - is this affecting anybody else?
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 14 Jan 2017, at 21:21, Adrien Grand  wrote:
>
> Le sam. 14 janv. 2017 à 10:39, Alan Woodward  a écrit :
>
> I’d like to land LUCENE-7627 and LUCENE-7628 before you cut the branch -
> will commit in the next couple of hours assuming all tests run.
>
>
> LUCENE-7628 feels a bit rushed in to me. Can we revert from the 6.4 branch
> to have a bit more time to discuss it?
>
>
>

[jira] [Commented] (LUCENE-7633) Rename Terms to FieldTerms

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7633:
--

I like Fields > Terms > TermsEnum better than Fields > FieldTerms > 
FieldTermsEnum. The renaming does not really clarify what those classes are 
about and increases verbosity, so I'd rather keep things as they are today.

> Rename Terms to FieldTerms
> --
>
> Key: LUCENE-7633
> URL: https://issues.apache.org/jira/browse/LUCENE-7633
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>




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

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

[jira] [Commented] (LUCENE-7623) Add FunctionScoreQuery and FunctionMatchQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7623:
--

Did you upload an old patch? It does not seem to have the changes you mentioned.

> Add FunctionScoreQuery and FunctionMatchQuery
> -
>
> Key: LUCENE-7623
> URL: https://issues.apache.org/jira/browse/LUCENE-7623
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch, 
> LUCENE-7623.patch
>
>
> We should update the various function scoring queries to use the new 
> DoubleValues API



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+152) - Build # 2672 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:41526/collection1]> but was:http://127.0.0.1:34852/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:41526/collection1]> but 
was:http://127.0.0.1:34852/collection1]>
at 
__randomizedtesting.SeedInfo.seed([ABD265ACE34A12C2:23865A764DB67F3A]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 
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 

[jira] [Comment Edited] (LUCENE-7623) Add FunctionScoreQuery and FunctionMatchQuery

[Alan Woodward (JIRA)]

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

Alan Woodward edited comment on LUCENE-7623 at 1/15/17 2:11 PM:


Thanks Adrien.  Here's an updated patch:
* Removes forSearcher() - I'd put this in initially so that we could create 
sources for particular IndexSearchers (by analogy to Query/Weight), but it 
isn't necessary for this patch.
* No more toString() impls on DoubleValues, explanations are now taken from 
their parent sources
* Tests don't depend on expressions, instead I've added a couple of helper 
functions to DoubleValuesSource that will apply DoubleFunctions to a wrapped 
source.
* Predicate -> DoublePredicate
* TODO added
* Changed the casting
* annotations removed


was (Author: romseygeek):
Thanks Adrien.  Here's an updated patch:
* Removes forSearcher() - I'd put this in initially so that we could create 
sources for particular IndexSearchers (by analogy to Query/Weight), but it 
isn't necessary for this patch.
* No more toString() impls on DoubleValues, explanations are now taken from 
their parent sources
* Tests don't depend on explanations, instead I've added a couple of helper 
functions to DoubleValuesSource that will apply DoubleFunctions to a wrapped 
source.
* Predicate -> DoublePredicate
* TODO added
* Changed the casting
* annotations removed

> Add FunctionScoreQuery and FunctionMatchQuery
> -
>
> Key: LUCENE-7623
> URL: https://issues.apache.org/jira/browse/LUCENE-7623
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch, 
> LUCENE-7623.patch
>
>
> We should update the various function scoring queries to use the new 
> DoubleValues API



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

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

[jira] [Updated] (LUCENE-7623) Add FunctionScoreQuery and FunctionMatchQuery

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-7623:
--
Attachment: LUCENE-7623.patch

Thanks Adrien.  Here's an updated patch:
* Removes forSearcher() - I'd put this in initially so that we could create 
sources for particular IndexSearchers (by analogy to Query/Weight), but it 
isn't necessary for this patch.
* No more toString() impls on DoubleValues, explanations are now taken from 
their parent sources
* Tests don't depend on explanations, instead I've added a couple of helper 
functions to DoubleValuesSource that will apply DoubleFunctions to a wrapped 
source.
* Predicate -> DoublePredicate
* TODO added
* Changed the casting
* annotations removed

> Add FunctionScoreQuery and FunctionMatchQuery
> -
>
> Key: LUCENE-7623
> URL: https://issues.apache.org/jira/browse/LUCENE-7623
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7623.patch, LUCENE-7623.patch, LUCENE-7623.patch, 
> LUCENE-7623.patch
>
>
> We should update the various function scoring queries to use the new 
> DoubleValues API



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

[Policeman Jenkins Server]

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

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

Error Message:
PeerSynced node did not become leader expected:http://127.0.0.1:65090/collection1]> but was:http://127.0.0.1:65072/collection1]>

Stack Trace:
java.lang.AssertionError: PeerSynced node did not become leader 
expected:http://127.0.0.1:65090/collection1]> but 
was:http://127.0.0.1:65072/collection1]>
at 
__randomizedtesting.SeedInfo.seed([72865ACCC763AB5A:FAD26516699FC6A2]: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.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:162)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[GitHub] lucene-solr pull request #139: Fieldterms

[PaulElschot]

GitHub user PaulElschot opened a pull request:

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

Fieldterms

LUCENE-7633

Rename Terms to FieldTerms.

The only reason for this is that the name Terms is a little too general.


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

$ git pull https://github.com/PaulElschot/lucene-solr fieldterms

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

https://github.com/apache/lucene-solr/pull/139.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #139


commit e0d64d786635da895a414a694c73efa6f2f34934
Author: Paul Elschot 
Date:   2017-01-15T12:50:28Z

Rename Terms to FieldTerms

commit f9716a7350187330cc326cec450f88d6eaa3a267
Author: Paul Elschot 
Date:   2017-01-15T13:07:23Z

Make solr ant compile-test pass for renaming Terms to FieldTerms




---
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-7633) Rename Terms to FieldTerms

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7633:


GitHub user PaulElschot opened a pull request:

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

Fieldterms

LUCENE-7633

Rename Terms to FieldTerms.

The only reason for this is that the name Terms is a little too general.


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

$ git pull https://github.com/PaulElschot/lucene-solr fieldterms

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

https://github.com/apache/lucene-solr/pull/139.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #139


commit e0d64d786635da895a414a694c73efa6f2f34934
Author: Paul Elschot 
Date:   2017-01-15T12:50:28Z

Rename Terms to FieldTerms

commit f9716a7350187330cc326cec450f88d6eaa3a267
Author: Paul Elschot 
Date:   2017-01-15T13:07:23Z

Make solr ant compile-test pass for renaming Terms to FieldTerms




> Rename Terms to FieldTerms
> --
>
> Key: LUCENE-7633
> URL: https://issues.apache.org/jira/browse/LUCENE-7633
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>




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

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

[jira] [Created] (LUCENE-7633) Rename Terms to FieldTerms

[Paul Elschot (JIRA)]

Paul Elschot created LUCENE-7633:


 Summary: Rename Terms to FieldTerms
 Key: LUCENE-7633
 URL: https://issues.apache.org/jira/browse/LUCENE-7633
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Paul Elschot






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

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

[jira] [Commented] (LUCENE-7624) Consider moving TermsQuery to core

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7624:
--

This one is an interesting target for surround, so I had a look.

Allowing more than one field for the terms also has an advantage in that only 
one doc id set will be built for all the terms.

As to the code: 
There is a small javadoc mistake in line 54 using both "@{" and "{@".
When constructing a Term a deep copy of the given BytesRef is taken, so the 
deep copy in line 154 is superfluous.
(The deep copy in line 222 of the termEnum.term() is needed there.)

> Consider moving TermsQuery to core
> --
>
> Key: LUCENE-7624
> URL: https://issues.apache.org/jira/browse/LUCENE-7624
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7624.patch
>
>
> TermsQuery current sits in the queries module, but it's used in both 
> spatial-extras and in facets, and currently is the only reason that the 
> facets module has a dependency on queries.  I think it's a generally useful 
> query, and would fit in perfectly well in core.
> This would also allow us to explore rewriting BooleanQuery to TermsQuery to 
> avoid the max-clauses limit



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

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

[jira] [Commented] (LUCENE-7628) Add a getMatchingChildren() method to DisjunctionScorer

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7628:
---

I've reverted the change.

To keep the API the same size, I can try merging the functionality of 
getChildren() and getMatchingChildren() (my second suggestion here: 
https://issues.apache.org/jira/browse/LUCENE-7628?focusedCommentId=15818614=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15818614).

On the issue of bulk scoring, maybe we should add a visitsSubScorers() method 
to Collector, analogous to needsScores().  Then we can enable bulk-scoring or 
not depending on the needs of the Collector implementation.  This would be 
another way to deal with LUCENE-7365.

> Add a getMatchingChildren() method to DisjunctionScorer
> ---
>
> Key: LUCENE-7628
> URL: https://issues.apache.org/jira/browse/LUCENE-7628
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.4
>
> Attachments: LUCENE-7628.patch
>
>
> This one is a bit convoluted, so bear with me...
> The luwak highlighter works by rewriting queries into their Span-equivalents, 
> and then running them with a special Collector.  At each matching doc, the 
> highlighter gathers all the Spans objects positioned on the current doc and 
> collects their positions using the SpanCollection API.
> Some queries can't be translated into Spans.  For those queries that generate 
> Scorers with ChildScorers, like BooleanQuery, we can call .getChildren() on 
> the Scorer and see if any of them are SpanScorers, and for those that aren't 
> we can call .getChildren() again and recurse down.  For each child scorer, we 
> check that it's positioned on the current document, so non-matching 
> subscorers can be skipped.
> This all works correctly *except* in the case of a DisjunctionScorer where 
> one of the children is a two-phase iterator that has matched its 
> approximation, but not its refinement query.  A SpanScorer in this situation 
> will be correctly positioned on the current document, but its Spans will be 
> in an undefined state, meaning the highlighter will either collect incorrect 
> hits, or it will throw an Exception and prevent hits being collected from 
> other subspans.
> We've tried various ways around this (including forking SpanNearQuery and 
> adding a bunch of slow position checks to it that are used only by the 
> highlighting code), but it turns out that the simplest fix is to add a new 
> method to DisjunctionScorer that only returns the currently matching child 
> Scorers.  It's a bit of a hack, and it won't be used anywhere else, but it's 
> a fairly small and contained hack.



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

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

[jira] [Reopened] (LUCENE-7628) Add a getMatchingChildren() method to DisjunctionScorer

[Alan Woodward (JIRA)]

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

Alan Woodward reopened LUCENE-7628:
---

> Add a getMatchingChildren() method to DisjunctionScorer
> ---
>
> Key: LUCENE-7628
> URL: https://issues.apache.org/jira/browse/LUCENE-7628
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 6.4
>
> Attachments: LUCENE-7628.patch
>
>
> This one is a bit convoluted, so bear with me...
> The luwak highlighter works by rewriting queries into their Span-equivalents, 
> and then running them with a special Collector.  At each matching doc, the 
> highlighter gathers all the Spans objects positioned on the current doc and 
> collects their positions using the SpanCollection API.
> Some queries can't be translated into Spans.  For those queries that generate 
> Scorers with ChildScorers, like BooleanQuery, we can call .getChildren() on 
> the Scorer and see if any of them are SpanScorers, and for those that aren't 
> we can call .getChildren() again and recurse down.  For each child scorer, we 
> check that it's positioned on the current document, so non-matching 
> subscorers can be skipped.
> This all works correctly *except* in the case of a DisjunctionScorer where 
> one of the children is a two-phase iterator that has matched its 
> approximation, but not its refinement query.  A SpanScorer in this situation 
> will be correctly positioned on the current document, but its Spans will be 
> in an undefined state, meaning the highlighter will either collect incorrect 
> hits, or it will throw an Exception and prevent hits being collected from 
> other subspans.
> We've tried various ways around this (including forking SpanNearQuery and 
> adding a bunch of slow position checks to it that are used only by the 
> highlighting code), but it turns out that the simplest fix is to add a new 
> method to DisjunctionScorer that only returns the currently matching child 
> Scorers.  It's a bit of a hack, and it won't be used anywhere else, but it's 
> a fairly small and contained hack.



--
This message was sent by Atlassian 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-9966) Convert/migrate tests using EasyMock to Mockito

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9966:
-

Easymock issue: https://github.com/easymock/easymock/issues/193

> Convert/migrate tests using EasyMock to Mockito
> ---
>
> Key: SOLR-9966
> URL: https://issues.apache.org/jira/browse/SOLR-9966
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Uwe Schindler
>
> In SOLR-9893 I disabled all tests on Java 9 that use EasyMock, because 
> Easymock is not compatible with Java 9 (it uses outdated cglib version that 
> does not work with Jigsaw module system). To me the project seems dead (no 
> releases since more than 2 years).
> Mockito latest version is compatible to Java 9 because it no longer uses 
> cglib and the more modern and powerful Byte-Buddy lib; SOLR-9893 updated to 
> it. 
> I found this about more or less "automated rewrite" of EasyMock tests to 
> Mockito:
> - 
> https://wiki.magnolia-cms.com/display/DEV/Converting+Easymock-Tests+to+Mockito
> - A script doing this: 
> https://gist.github.com/stefanbirkner/1095194/904909cc229b6acb55c18f529e396089129e20e9
> It is not many tests, so this would be a great cleanup:
> - core/src/test/org/apache/solr/cloud/ClusterStateTest.java
> - 
> core/src/test/org/apache/solr/cloud/OverseerCollectionConfigSetProcessorTest.java
> - core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java
> - core/src/test/org/apache/solr/core/CoreSorterTest.java
> - core/src/test/org/apache/solr/security/TestPKIAuthenticationPlugin.java
> - core/src/test/org/apache/solr/servlet/SolrRequestParserTest.java
> - 
> solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrClientCacheTest.java
> There is one special case:
> - 
> contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSource.java
> I am not sure how to convert this one, because it uses some strange system 
> properties and a handler that intercepts some EasyMock stuff. I may need help 
> to convert that one!
> After this is resolved we can remove the following dependencies from Solr:
> - cglib-nodep
> - easymock



--
This message was sent by Atlassian 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: 6.4 release

[Alan Woodward]

Sure, I’ll revert it this morning.

As an aside, I don’t seem to be getting email notifications from JIRA anymore - 
is this affecting anybody else?

Alan Woodward
www.flax.co.uk


> On 14 Jan 2017, at 21:21, Adrien Grand  wrote:
> 
> Le sam. 14 janv. 2017 à 10:39, Alan Woodward  > a écrit :
> I’d like to land LUCENE-7627 and LUCENE-7628 before you cut the branch - will 
> commit in the next couple of hours assuming all tests run.
> 
> LUCENE-7628 feels a bit rushed in to me. Can we revert from the 6.4 branch to 
> have a bit more time to discuss it?

[jira] [Commented] (SOLR-9893) EasyMock/Mockito no longer works with Java 9 b148+

[ASF subversion and git services (JIRA)]

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

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

Commit 47b25354d721a47211294690aee3096f78ccd6a4 in lucene-solr's branch 
refs/heads/branch_6_4 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=47b2535 ]

SOLR-9893: For full Java 9 compatibility also update to latest Objenesis 2.5 
(this allows mocking frameworks to instantiate objects without a ctor)


> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 6.x, master (7.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Attachments: SOLR-9893.patch, SOLR-9893.patch
>
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



--
This message was sent by Atlassian 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-9893) EasyMock/Mockito no longer works with Java 9 b148+

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9893: For full Java 9 compatibility also update to latest Objenesis 2.5 
(this allows mocking frameworks to instantiate objects without a ctor)


> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 6.x, master (7.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Attachments: SOLR-9893.patch, SOLR-9893.patch
>
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



--
This message was sent by Atlassian 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-9893) EasyMock/Mockito no longer works with Java 9 b148+

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9893: For full Java 9 compatibility also update to latest Objenesis 2.5 
(this allows mocking frameworks to instantiate objects without a ctor)


> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: 6.x, master (7.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Attachments: SOLR-9893.patch, SOLR-9893.patch
>
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



--
This message was sent by Atlassian 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-9966) Convert/migrate tests using EasyMock to Mockito

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9966:
-

FYI, the CGLIB issue is: https://github.com/cglib/cglib/issues/93
It is fixed in Git, but as far as I know, no new release.

> Convert/migrate tests using EasyMock to Mockito
> ---
>
> Key: SOLR-9966
> URL: https://issues.apache.org/jira/browse/SOLR-9966
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Uwe Schindler
>
> In SOLR-9893 I disabled all tests on Java 9 that use EasyMock, because 
> Easymock is not compatible with Java 9 (it uses outdated cglib version that 
> does not work with Jigsaw module system). To me the project seems dead (no 
> releases since more than 2 years).
> Mockito latest version is compatible to Java 9 because it no longer uses 
> cglib and the more modern and powerful Byte-Buddy lib; SOLR-9893 updated to 
> it. 
> I found this about more or less "automated rewrite" of EasyMock tests to 
> Mockito:
> - 
> https://wiki.magnolia-cms.com/display/DEV/Converting+Easymock-Tests+to+Mockito
> - A script doing this: 
> https://gist.github.com/stefanbirkner/1095194/904909cc229b6acb55c18f529e396089129e20e9
> It is not many tests, so this would be a great cleanup:
> - core/src/test/org/apache/solr/cloud/ClusterStateTest.java
> - 
> core/src/test/org/apache/solr/cloud/OverseerCollectionConfigSetProcessorTest.java
> - core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java
> - core/src/test/org/apache/solr/core/CoreSorterTest.java
> - core/src/test/org/apache/solr/security/TestPKIAuthenticationPlugin.java
> - core/src/test/org/apache/solr/servlet/SolrRequestParserTest.java
> - 
> solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrClientCacheTest.java
> There is one special case:
> - 
> contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSource.java
> I am not sure how to convert this one, because it uses some strange system 
> properties and a handler that intercepts some EasyMock stuff. I may need help 
> to convert that one!
> After this is resolved we can remove the following dependencies from Solr:
> - cglib-nodep
> - easymock



--
This message was sent by Atlassian 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-9966) Convert/migrate tests using EasyMock to Mockito

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9966:
-

Hi Henri,
the problem is that Solr tests are using 2 different frameworks for mocking and 
a cleanup would be fine. So based on statistics on Solr's Code Mockito is more 
used and EasyMock is only used with some legacy tests.
To fix the Java 9 problem, you have to first wait for a release of CGLIB.
Uwe

> Convert/migrate tests using EasyMock to Mockito
> ---
>
> Key: SOLR-9966
> URL: https://issues.apache.org/jira/browse/SOLR-9966
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Uwe Schindler
>
> In SOLR-9893 I disabled all tests on Java 9 that use EasyMock, because 
> Easymock is not compatible with Java 9 (it uses outdated cglib version that 
> does not work with Jigsaw module system). To me the project seems dead (no 
> releases since more than 2 years).
> Mockito latest version is compatible to Java 9 because it no longer uses 
> cglib and the more modern and powerful Byte-Buddy lib; SOLR-9893 updated to 
> it. 
> I found this about more or less "automated rewrite" of EasyMock tests to 
> Mockito:
> - 
> https://wiki.magnolia-cms.com/display/DEV/Converting+Easymock-Tests+to+Mockito
> - A script doing this: 
> https://gist.github.com/stefanbirkner/1095194/904909cc229b6acb55c18f529e396089129e20e9
> It is not many tests, so this would be a great cleanup:
> - core/src/test/org/apache/solr/cloud/ClusterStateTest.java
> - 
> core/src/test/org/apache/solr/cloud/OverseerCollectionConfigSetProcessorTest.java
> - core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java
> - core/src/test/org/apache/solr/core/CoreSorterTest.java
> - core/src/test/org/apache/solr/security/TestPKIAuthenticationPlugin.java
> - core/src/test/org/apache/solr/servlet/SolrRequestParserTest.java
> - 
> solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrClientCacheTest.java
> There is one special case:
> - 
> contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/TestJdbcDataSource.java
> I am not sure how to convert this one, because it uses some strange system 
> properties and a handler that intercepts some EasyMock stuff. I may need help 
> to convert that one!
> After this is resolved we can remove the following dependencies from Solr:
> - cglib-nodep
> - easymock



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

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