date:20161008

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

2016-10-08 Thread Policeman Jenkins Server

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

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

Error Message:
Error from server at http://127.0.0.1:53265/jd/pj/c8n_1x2_shard1_replica1: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /jd/pj/c8n_1x2_shard1_replica1/update. Reason: Not 
Found http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314   

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:53265/jd/pj/c8n_1x2_shard1_replica1: Expected mime 
type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /jd/pj/c8n_1x2_shard1_replica1/update. Reason:
Not Found
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314



at 
__randomizedtesting.SeedInfo.seed([62308C8551BE9D75:EA64B35FFF42F08D]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:609)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:595)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:294)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at

[jira] [Updated] (SOLR-8241) Evaluate W-TinyLfu cache

2016-10-08 Thread Ben Manes (JIRA)


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

Ben Manes updated SOLR-8241:

Attachment: proposal.patch

I have some basic tests ported (testSimple, testTimeDecay). The first performs 
access operations and the second ensures frequency is taken into account. The 
changes also adds cumulative stats by aggregating during warm() (this was 
simpler than the init approach since Caffeine's stats object is immutable).

Minor changes are to rename the class to TinyLfuCache to emphasize the policy 
over the library. That conforms with the HBase and Accumulo integration, and 
matches the existing naming convention.

This version of the patch requires changes in Caffeine 2.3.4-SNAPSHOT. I 
improved the hot iteration order which previously returned in warm, hot, cold 
order. Given real world cache sizes it might not have made a difference, but 
was a required improvement for the tests. So I'm adding this version as a 
proposal and can cut a release when you're ready for integration.

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch, SOLR-8241.patch, proposal.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_102) - Build # 18003 - Unstable!

2016-10-08 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18003/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Shard a1x2_shard1_replica2 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica2 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([3234C3AEE939FE88:BA60FC7447C59370]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:122)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
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] (SOLR-8241) Evaluate W-TinyLfu cache

2016-10-08 Thread Ben Manes (JIRA)


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

Ben Manes commented on SOLR-8241:
-

I think there is a small bug in the "hottest" ordering provided by Caffeine, so 
the warmed-up cache doesn't contain the desired entries. I believe this is a 
simple mistake of concatenating two lists in the wrong order, so that it 
chooses a luke-warm entry instead. I'm not sure how to test my changes to 
verify this with a custom jar in Ivy, though.

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch, SOLR-8241.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



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

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

[jira] [Closed] (SOLR-8316) Allow a field to be stored=false indexed=false docValues=true

2016-10-08 Thread Erick Erickson (JIRA)


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

Erick Erickson closed SOLR-8316.

Resolution: Duplicate

Seel SOLR-8220

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



--
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-7283) Move SlowCompositeReaderWrapper and uninverting package to solr sources

2016-10-08 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on LUCENE-7283:
--

bq. In ancient Lucene versions, sorting was not a "first class citizen" and 
hacks like field cache were necessary.

Yes, a hack that has been with us for more than *12 years* already (FieldCache 
came about in 2004).

Best practice is one thing (Solr uses docvalues by default), but removing the 
option is different.

After a quick google, it doesn't appear like you're removing this ability from 
elasticsearch (fielddata is the ES equivalent of the Lucene FieldCache):
https://www.elastic.co/guide/en/elasticsearch/reference/5.x/modules-fielddata.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/fielddata.html



> Move SlowCompositeReaderWrapper and uninverting package to solr sources
> ---
>
> Key: LUCENE-7283
> URL: https://issues.apache.org/jira/browse/LUCENE-7283
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7283.patch
>
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first 
> class support in Lucene's ore, and no longer use 
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N 
> segments is actually just a single segment.  It's a leaky abstraction, has 
> poor performance, and puts undue pressure on the APIs of new Lucene features 
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for 
> {{UninvertedReader}} tests, which should maybe also move out?) has been 
> removed from Lucene, so I think we should move it to Solr.  This may also 
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's 
> schema to "know" how to handle points fields properly.



--
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-Windows (32bit/jdk1.8.0_102) - Build # 6167 - Still Failing!

2016-10-08 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6167/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousAddsViaShard1NonLeaderClient

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([A1779DCC8FE98CA2:53B5634571832994]:0)
at java.util.HashMap.newNode(HashMap.java:1742)
at java.util.HashMap.putVal(HashMap.java:630)
at java.util.HashMap.put(HashMap.java:611)
at java.util.HashSet.add(HashSet.java:219)
at 
sun.security.util.AlgorithmDecomposer.decompose(AlgorithmDecomposer.java:76)
at 
sun.security.ssl.SSLAlgorithmDecomposer.decompose(SSLAlgorithmDecomposer.java:248)
at 
sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(AbstractAlgorithmConstraints.java:104)
at 
sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:91)
at 
sun.security.ssl.SSLAlgorithmConstraints.permits(SSLAlgorithmConstraints.java:144)
at 
sun.security.ssl.SignatureAndHashAlgorithm.getSupportedAlgorithms(SignatureAndHashAlgorithm.java:158)
at 
sun.security.ssl.Handshaker.getLocalSupportedSignAlgs(Handshaker.java:442)
at 
sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1392)
at sun.security.ssl.Handshaker.kickstart(Handshaker.java:1014)
at 
sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1487)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)




Build Log:
[...truncated 10819 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestTolerantUpdateProcessorCloud
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestTolerantUpdateProcessorCloud_A1779DCC8FE98CA2-001\init-core-data-001
   [junit4]   2> 343800 INFO  
(SUITE-TestTolerantUpdateProcessorCloud-seed#[A1779DCC8FE98CA2]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 343803 INFO  
(SUITE-TestTolerantUpdateProcessorCloud-seed#[A1779DCC8FE98CA2]-worker) [] 
o.a.s.c.MiniSolrCloudCluster Starting cluster of 5 servers in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestTolerantUpdateProcessorCloud_A1779DCC8FE98CA2-001\tempDir-001
   [junit4]   2> 343803 INFO  
(SUITE-TestTolerantUpdateProcessorCloud-seed#[A1779DCC8FE98CA2]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 343804 INFO  (Thread-786) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 343804 INFO  (Thread-786) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 343905 INFO  
(SUITE-TestTolerantUpdateProcessorCloud-seed#[A1779DCC8FE98CA2]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:61825
   [junit4]   2> 343917 WARN  (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] 
o.a.z.s.NIOServerCnxn caught end of stream exception
   [junit4]   2> EndOfStreamException: Unable to read

[jira] [Commented] (LUCENE-7283) Move SlowCompositeReaderWrapper and uninverting package to solr sources

2016-10-08 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-7283:


bq.  I imagine they will be quite surprised to see everything about the 
FieldCache removed and left with no ability to Sort on an indexed-only field.

I doubt that.

In ancient Lucene versions, sorting was not a "first class citizen" and hacks 
like field cache were necessary.

But then, long ago, we added doc values, and we've been saying for years now 
that if you want to sort by X you need to index X as doc values.  This change 
(in 7.0 only, just deprecated in 6.x) should come as a surprise to nobody.

Doc values are far more efficient than the the legacy field cache: no up front 
penalty the first time you sort on the field, no massive heap usage, no heavy 
full GC cost. Instead the OS manages the hot pages and swaps as necessary, 
thanks to efficient doc values codec formats.

And such theoretical users have plenty of options: they can use Solr, or only 
use {{UninvertingReader}} or {{SlowCompositeReaderWrapper}} out of Solr's 
sources, or fork them for their own purposes, or reindex with the 
much-more-efficient doc values.

Such horribly inefficient legacy code really does not belong in Lucene (or 
Solr!).

> Move SlowCompositeReaderWrapper and uninverting package to solr sources
> ---
>
> Key: LUCENE-7283
> URL: https://issues.apache.org/jira/browse/LUCENE-7283
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7283.patch
>
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first 
> class support in Lucene's ore, and no longer use 
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N 
> segments is actually just a single segment.  It's a leaky abstraction, has 
> poor performance, and puts undue pressure on the APIs of new Lucene features 
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for 
> {{UninvertedReader}} tests, which should maybe also move out?) has been 
> removed from Lucene, so I think we should move it to Solr.  This may also 
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's 
> schema to "know" how to handle points fields properly.



--
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-8241) Evaluate W-TinyLfu cache

2016-10-08 Thread Ben Manes (JIRA)


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

Ben Manes commented on SOLR-8241:
-

I can take a stab at tests, but its unclear what to include other than basic 
operations. Otherwise I'd defer to the library for deeper testing, e.g. scan 
resistance and efficiency. In those areas writing tests is for the author to 
have assurance that the library does what it claims. I'd prefer if someone 
obtained production traces instead, which I think would show you an interesting 
hit rate curve for how the policies stack up.

I'm pretty sure the current warming, which populates with the hottest entries 
first, should be good enough. Since reads dominate writes, the hot entries will 
quickly have a high frequency by the time an eviction is triggered. We can try 
to give the first few hot entries a small bump too, by adding a few accesses, 
to add an extra nudge.

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch, SOLR-8241.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



--
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-8241) Evaluate W-TinyLfu cache

2016-10-08 Thread Shawn Heisey (JIRA)


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

Shawn Heisey updated SOLR-8241:
---
Attachment: SOLR-8241.patch

Updated patch against master.  Changes from the previous version:

No changes to SolrCache.java -- those were whitespace only.  I've also upgraded 
to the newest version of Caffeine currently available (2.3.3).  Removed the 
unused RemovalCause import.  Precommit passes.

At this time, I am leaving LFUCache alone and keeping the new cache as a class 
addition.  I will make a decision later about whether to replace LFUCache.

I don't have a CHANGES.txt entry yet.  That will go in last, once we nail down 
what version gets the change.  I haven't done anything with tests yet.

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch, SOLR-8241.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



--
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-8241) Evaluate W-TinyLfu cache

2016-10-08 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-8241:


Taking a look at this today.

Would you be able to build some tests?  I can copy the existing LFUCache tests 
and modify them until they pass, but it would be better for somebody who knows 
how the cache is *supposed* to work to engineer those tests so they check for 
what *should* happen.  Best possible result would be that my assumptions for 
LFUCache will hold without changes, but that is probably not likely.

New cache warming loses old frequency information, as I already mentioned 
earlier.  I suspect that even without this being preserved, we're likely to see 
a generally higher hitrate than LRU.  I would like to preserve this information 
if possible, but I don't view it as a blocker.

> Evaluate W-TinyLfu cache
> 
>
> Key: SOLR-8241
> URL: https://issues.apache.org/jira/browse/SOLR-8241
> Project: Solr
>  Issue Type: Wish
>  Components: search
>Reporter: Ben Manes
>Priority: Minor
> Attachments: SOLR-8241.patch
>
>
> SOLR-2906 introduced an LFU cache and in-progress SOLR-3393 makes it O(1). 
> The discussions seem to indicate that the higher hit rate (vs LRU) is offset 
> by the slower performance of the implementation. An original goal appeared to 
> be to introduce ARC, a patented algorithm that uses ghost entries to retain 
> history information.
> My analysis of Window TinyLfu indicates that it may be a better option. It 
> uses a frequency sketch to compactly estimate an entry's popularity. It uses 
> LRU to capture recency and operate in O(1) time. When using available 
> academic traces the policy provides a near optimal hit rate regardless of the 
> workload.
> I'm getting ready to release the policy in Caffeine, which Solr already has a 
> dependency on. But, the code is fairly straightforward and a port into Solr's 
> caches instead is a pragmatic alternative. More interesting is what the 
> impact would be in Solr's workloads and feedback on the policy's design.
> https://github.com/ben-manes/caffeine/wiki/Efficiency



--
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-8316) Allow a field to be stored=false indexed=false docValues=true

2016-10-08 Thread Keith Laban (JIRA)


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

Keith Laban commented on SOLR-8316:
---

Yes this can be closed

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



--
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-9612) Stored field access should be avoided when it's not needed

2016-10-08 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-9612:
--

Hmm, how does this relate to SOLR-8220? In particular, what happens if you 
specify "useDocValuesAsStored" (see the discussion at SOLR-8220).

I haven't looked deeply into this so that link may be off base. But this work 
may already be done

> Stored field access should be avoided when it's not needed
> --
>
> Key: SOLR-9612
> URL: https://issues.apache.org/jira/browse/SOLR-9612
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers, search
>Affects Versions: 6.0, 6.1, 6.2
>Reporter: Takahiro Ishikawa
>Priority: Minor
>  Labels: performance
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9612.patch
>
>
> This is a small enhancement. (unneeded stored access spend 5% in my profile 
> result)
> All fields which is written in fl parameter(some of them are only doc values 
> not stored) are iterated over from stored fields and it's inefficient. 
> Further when fl parameters are only docValues, we should avoid accessing 
> stored.
> I'm going to update a conservative patch.
> This patch exclude nonStoredDocValues fields from stored field list, and if 
> we don't need access stored, we skip it.
> What 'conservative' means is that when schema is dynamically changed this 
> patch not change behaviors.(ex. stored field 'a' is removed from schema, and 
> user search fl=a, then a is returned from DocStreamer.)
> But I'm not sure how should solr behaves when schema is dynamically changed.
> I think better approach is 
> Each fields are classified 3 types from schema and process each.
>  - stored   -> fetch from stored
>  - nonStoredDocValues   -> fetch from docValues
>  - unknown  -> error or lazy field(distinguishable?)
> But this might break backward compatibility.(like mentioned above)
> Any comments are welcome.



--
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-8316) Allow a field to be stored=false indexed=false docValues=true

2016-10-08 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-8316:
--

Can this be closed? Seems like 8220 handles it.

> Allow a field to be stored=false indexed=false docValues=true
> -
>
> Key: SOLR-8316
> URL: https://issues.apache.org/jira/browse/SOLR-8316
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>
> Right now if you try to index a field which is not stored or indexed you will 
> get an exception, however sometimes it makes sense to have a field which only 
> has docValues on for example see [SOLR-8220]



--
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-7283) Move SlowCompositeReaderWrapper and uninverting package to solr sources

2016-10-08 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on LUCENE-7283:
--

bq. p.s. please update the description to include UninvertingReader (which is 
much larger in scope than just SCW and unrelated to SCW)

Indeed, the original JIRA description of "Move SlowCompositeReaderWrapper to 
solr sources" doesn't begin to describe the impact this issue will have on 
normal Lucene users in 7.0.  I imagine they will be quite surprised to see 
everything about the FieldCache removed and left with no ability to Sort on an 
indexed-only field.

It really seems like there should be a lot more consensus around removing 
functionality on this scale.

> Move SlowCompositeReaderWrapper and uninverting package to solr sources
> ---
>
> Key: LUCENE-7283
> URL: https://issues.apache.org/jira/browse/LUCENE-7283
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.1, master (7.0)
>
> Attachments: LUCENE-7283.patch
>
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first 
> class support in Lucene's ore, and no longer use 
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N 
> segments is actually just a single segment.  It's a leaky abstraction, has 
> poor performance, and puts undue pressure on the APIs of new Lucene features 
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for 
> {{UninvertedReader}} tests, which should maybe also move out?) has been 
> removed from Lucene, so I think we should move it to Solr.  This may also 
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's 
> schema to "know" how to handle points fields properly.



--
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: [GitHub] lucene-solr issue #66: SOLR-8146: Allowing SolrJ CloudSolrClient to have pre...

2016-10-08 Thread Susheel Kumar

Hello Noble,

I have merged the routingRule changes on the refactored latest code, have
added ClientSnitchContext class. Please have a look.

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

Thanks,
Susheel

On Sat, Oct 8, 2016 at 12:11 PM, susheelks  wrote:

> Github user susheelks commented on the issue:
>
> https://github.com/apache/lucene-solr/pull/66
>
> Merged routingRule changes after latest refactored code
>
>
> ---
> 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] (SOLR-8146) Allowing SolrJ CloudSolrClient to have preferred replica for query/read

2016-10-08 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-8146:
--

Github user susheelks commented on the issue:

https://github.com/apache/lucene-solr/pull/66
  
Merged routingRule changes after latest refactored code


> Allowing SolrJ CloudSolrClient to have preferred replica for query/read
> ---
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch, 
> SOLR-8146.patch
>
>
> h2. Backgrouds
> Currently, the CloudSolrClient randomly picks a replica to query.
> This is done by shuffling the list of live URLs to query then, picking the 
> first item from the list.
> This ticket is to allow more flexibility and control to some extend which 
> URLs will be picked up for queries.
> Note that this is for queries only and would not affect update/delete/admin 
> operations.
> h2. Implementation
> The current patch uses regex pattern and moves to the top of the list of URLs 
> only those matching the given regex specified by the system property 
> {code}solr.preferredQueryNodePattern{code}
> Initially, I thought it may be good to have Solr nodes tagged with a string 
> pattern (snitch?) and use that pattern for matching the URLs.
> Any comment, recommendation or feedback would be appreciated.
> h2. Use Cases
> There are many cases where the ability to choose the node where queries go 
> can be very handy:
> h3. Special node for manual user queries and analytics
> One may have a SolrCLoud cluster where every node host the same set of 
> collections with:  
> - multiple large SolrCLoud nodes (L) used for production apps and 
> - have 1 small node (S) in the same cluster with less ram/cpu used only for 
> manual user queries, data export and other production issue investigation.
> This ticket would allow to configure the applications using SolrJ to query 
> only the (L) nodes
> This use case is similar to the one described in SOLR-5501 raised by [~manuel 
> lenormand]
> h3. Minimizing network traffic
>  
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 (or 
> N) separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.



--
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 issue #66: SOLR-8146: Allowing SolrJ CloudSolrClient to have pre...

2016-10-08 Thread susheelks

Github user susheelks commented on the issue:

https://github.com/apache/lucene-solr/pull/66
  
Merged routingRule changes after latest refactored code


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

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

[jira] [Created] (SOLR-9613) core or collection -> dataimport dangerous default

2016-10-08 Thread Matthew Sporleder (JIRA)

Matthew Sporleder created SOLR-9613:
---

 Summary: core or collection -> dataimport dangerous default
 Key: SOLR-9613
 URL: https://issues.apache.org/jira/browse/SOLR-9613
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: web gui
Reporter: Matthew Sporleder


When browsing to dataimport in the web gui and selecting "delta-import" from 
the drop down, the "full-import" checkbox selections stay checked, including 
"clean", which is very dangerous for a delta-import, as it deletes most of your 
data!

a js event to clear those checkboxes on selection from that dropdown would save 
a lot of accidental anguish.

{code}
var foo = document.getElementById("command")
function bar() { document.getElementById("clean").checked = false; }
foo.onchange = function() {
  if (foo.value == "delta-import")
{
  bar();
}
};
{code}

or whatever



--
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-7438) UnifiedHighlighter

2016-10-08 Thread David Smiley (JIRA)


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

David Smiley commented on LUCENE-7438:
--

Thanks for fixing the build Mike!  My bad.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, 
> LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



--
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-9608) ConnectionReuseTest failures

2016-10-08 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-9608:
-

The javadoc on HttpClientUtil.createNewHttpClientRequestContext() is incorrect 
now (it still talks about passing in a cache object), but +1 other than that.

> ConnectionReuseTest failures
> 
>
> Key: SOLR-9608
> URL: https://issues.apache.org/jira/browse/SOLR-9608
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Alan Woodward
> Attachments: SOLR-9608-6x.patch, SOLR-9608-6x.patch, 
> SOLR-9608-6x.patch, SOLR-9608-6x.patch, SOLR-9608.patch
>
>
> My Jenkins has seen this test fail three times in the last couple hours, all 
> three reproduce for me - this is new, last failures were from May - here's 
> the first failure:
> {noformat}
> Checking out Revision 0eb6b1c823d347319cc0894b5fea95f085d4c8d4 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ConnectionReuseTest -Dtests.method=testConnectionReuse 
> -Dtests.seed=FA03A6C483303E7D -Dtests.slow=true -Dtests.locale=ga 
> -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.09s J9  | ConnectionReuseTest.testConnectionReuse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: We expected all 
> communication to use one connection! HttpSolrClient 1
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([FA03A6C483303E7D:DB3BCDAAAB786730]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.ConnectionReuseTest.testConnectionReuse(ConnectionReuseTest.java:158)
> {noformat}
> This test failed for me twice without specifying a seed, so it's likely 
> failing (close to) 100% of the time.



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1900 - Failure!

2016-10-08 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1900/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrVersionReplicationTest.testCdcrDocVersions

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

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:44969/solr within 1 ms
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:182)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:106)
at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:226)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:567)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForCollectionToDisappear(BaseCdcrDistributedZkTest.java:494)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.startServers(BaseCdcrDistributedZkTest.java:596)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.createSourceCollection(BaseCdcrDistributedZkTest.java:346)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.baseBefore(BaseCdcrDistributedZkTest.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:905)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

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

2016-10-08 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6166/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 53365 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: C:\Users\jenkins\AppData\Local\Temp\ecj526087130
 [ecj-lint] Compiling 127 source files to 
C:\Users\jenkins\AppData\Local\Temp\ecj526087130
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 21)
 [ecj-lint] import java.util.Collection;
 [ecj-lint]
 [ecj-lint] The import java.util.Collection is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 22)
 [ecj-lint] import java.util.HashSet;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashSet is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 24)
 [ecj-lint] import java.util.List;
 [ecj-lint]^^
 [ecj-lint] The import java.util.List is never used
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 25)
 [ecj-lint] import java.util.Set;
 [ecj-lint]^
 [ecj-lint] The import java.util.Set is never used
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 27)
 [ecj-lint] import org.apache.lucene.analysis.Analyzer;
 [ecj-lint]^^^
 [ecj-lint] The import org.apache.lucene.analysis.Analyzer is never used
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\benchmark\src\java\org\apache\lucene\benchmark\byTask\tasks\ReadTask.java
 (at line 33)
 [ecj-lint] import org.apache.lucene.index.IndexableField;
 [ecj-lint]^^
 [ecj-lint] The import org.apache.lucene.index.IndexableField is never used
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:765: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:101: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build.xml:204: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2177:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:1992:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2031:
 Compile failed; see the compiler error output for details.

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



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

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

2016-10-08 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17998/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

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

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


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

Error Message:
Captured an uncaught exception in thread: Thread[id=70702, 
name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=70702, 
name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, 
group=TGRP-CdcrVersionReplicationTest]
Caused by: java.lang.OutOfMemoryError: Java heap space
at __randomizedtesting.SeedInfo.seed([A19FBFD7ED05AFF8]:0)
at java.io.BufferedReader.(BufferedReader.java:105)
at java.io.BufferedReader.(BufferedReader.java:116)
at java.io.LineNumberReader.(LineNumberReader.java:72)
at 
org.apache.log4j.DefaultThrowableRenderer.render(DefaultThrowableRenderer.java:64)
at 
org.apache.log4j.spi.ThrowableInformation.getThrowableStrRep(ThrowableInformation.java:87)
at 
org.apache.log4j.spi.LoggingEvent.getThrowableStrRep(LoggingEvent.java:413)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:313)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at 
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:478)
at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:357)
at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.CdcrVersionReplicationTest.testCdcrDocVersions

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([A19FBFD7ED05AFF8]:0)




Build Log:
[...truncated 12757 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrVersionReplicationTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrVersionReplicationTest_A19FBFD7ED05AFF8-001/init-core-data-001
   [junit4]   2> 1435265 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[A19FBFD7ED05AFF8]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1435266 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[A19FBFD7ED05AFF8]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/ut_ngd/
   [junit4]   2> 1435268 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[A19FBFD7ED05AFF8]) [ 
   ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1435268 INFO  (Thread-2817) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1435268 INFO  (Thread-2817) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1435368 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[A19FBFD7ED05AFF8]) [ 
   ] o.a.s.c.ZkTestServer start zk server on port:46742
   [junit4]   2> 1435382 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[A19FBFD7ED05AFF8]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-cdcr.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1435385 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[A19FBFD7ED05AFF8]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1435387 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[A19FBFD7ED05AFF8]) [ 
   ] o.a.s.c.AbstractZkTestCase put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1435389 INFO

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

2016-10-08 Thread ASF subversion and git services (JIRA)


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

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

Commit f247acfab17a5363166eb601cb26243e74ca108c in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f247acf ]

LUCENE-7438: fix broken build


> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, 
> LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

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

Re: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3591 - Still Failing!

2016-10-08 Thread Michael McCandless

I pushed a fix ... please remember to run "ant precommit" before pushing!

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 8, 2016 at 12:58 AM, Policeman Jenkins Server
 wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3591/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC
>
> All tests passed
>
> Build Log:
> [...truncated 53269 lines...]
> -ecj-javadoc-lint-src:
> [mkdir] Created dir: 
> /var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1502055439
>  [ecj-lint] Compiling 127 source files to 
> /var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1502055439
>  [ecj-lint] --
>  [ecj-lint] 1. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 21)
>  [ecj-lint] import java.util.Collection;
>  [ecj-lint]
>  [ecj-lint] The import java.util.Collection is never used
>  [ecj-lint] --
>  [ecj-lint] 2. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 22)
>  [ecj-lint] import java.util.HashSet;
>  [ecj-lint]^
>  [ecj-lint] The import java.util.HashSet is never used
>  [ecj-lint] --
>  [ecj-lint] 3. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 24)
>  [ecj-lint] import java.util.List;
>  [ecj-lint]^^
>  [ecj-lint] The import java.util.List is never used
>  [ecj-lint] --
>  [ecj-lint] 4. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 25)
>  [ecj-lint] import java.util.Set;
>  [ecj-lint]^
>  [ecj-lint] The import java.util.Set is never used
>  [ecj-lint] --
>  [ecj-lint] 5. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 27)
>  [ecj-lint] import org.apache.lucene.analysis.Analyzer;
>  [ecj-lint]^^^
>  [ecj-lint] The import org.apache.lucene.analysis.Analyzer is never used
>  [ecj-lint] --
>  [ecj-lint] 6. ERROR in 
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
>  (at line 33)
>  [ecj-lint] import org.apache.lucene.index.IndexableField;
>  [ecj-lint]^^
>  [ecj-lint] The import org.apache.lucene.index.IndexableField is never used
>  [ecj-lint] --
>  [ecj-lint] 6 problems (6 errors)
>
> BUILD FAILED
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:765: The 
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The 
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:204: The 
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2177:
>  The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:1992:
>  The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2031:
>  Compile failed; see the compiler error output for details.
>
> Total time: 107 minutes 5 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

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

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

2016-10-08 Thread ASF subversion and git services (JIRA)


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

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

Commit 0414570348e5b8c8c3da8b1ad491b1b418a3756a in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0414570 ]

LUCENE-7438: fix broken build


> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, 
> LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

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

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

2016-10-08 Thread Policeman Jenkins Server

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

All tests passed

Build Log:
[...truncated 53372 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /var/tmp/ecj2053804128
 [ecj-lint] Compiling 127 source files to /var/tmp/ecj2053804128
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 21)
 [ecj-lint] import java.util.Collection;
 [ecj-lint]
 [ecj-lint] The import java.util.Collection is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 22)
 [ecj-lint] import java.util.HashSet;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashSet is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 24)
 [ecj-lint] import java.util.List;
 [ecj-lint]^^
 [ecj-lint] The import java.util.List is never used
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 25)
 [ecj-lint] import java.util.Set;
 [ecj-lint]^
 [ecj-lint] The import java.util.Set is never used
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 27)
 [ecj-lint] import org.apache.lucene.analysis.Analyzer;
 [ecj-lint]^^^
 [ecj-lint] The import org.apache.lucene.analysis.Analyzer is never used
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/benchmark/src/java/org/apache/lucene/benchmark/byTask/tasks/ReadTask.java
 (at line 33)
 [ecj-lint] import org.apache.lucene.index.IndexableField;
 [ecj-lint]^^
 [ecj-lint] The import org.apache.lucene.index.IndexableField is never used
 [ecj-lint] --
 [ecj-lint] 6 problems (6 errors)

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:765: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/build.xml:204: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2177:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:1992:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2031:
 Compile failed; see the compiler error output for details.

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



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

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

2016-10-08 Thread Policeman Jenkins Server

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([A7232A3CB336DE36:5050C46475DE71D0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1329)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




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

[jira] [Closed] (SOLR-2025) SpellCheckResponse --.ClassCastException: org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-2025.
---
Resolution: Cannot Reproduce

> SpellCheckResponse --.ClassCastException: 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List
> ---
>
> Key: SOLR-2025
> URL: https://issues.apache.org/jira/browse/SOLR-2025
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.4.1
>Reporter: Reuben Firmin
>
> org.apache.solr.client.solrj.SolrServerException: Error executing query
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:118)
> ...
> Caused by: java.lang.ClassCastException: 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List
> at 
> org.apache.solr.client.solrj.response.SpellCheckResponse$Suggestion.(SpellCheckResponse.java:107)
> at 
> org.apache.solr.client.solrj.response.SpellCheckResponse.(SpellCheckResponse.java:51)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.extractSpellCheckInfo(QueryResponse.java:125)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:115)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.(QueryResponse.java:80)
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)



--
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 issue #90: fixed some CSS syntax errors in Solr webapp

2016-10-08 Thread arafalov

Github user arafalov commented on the issue:

https://github.com/apache/lucene-solr/pull/90
  
Ok. I will incorporate them the next time I am updating Admin UI (couple of 
weeks from now, most likely).

Thank you for the contribution.


---
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] (SOLR-2025) SpellCheckResponse --.ClassCastException: org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List

2016-10-08 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-2025:


An acient bug that can not be reprocedure in the lastest source of Solr. I've 
tried serveral tests to simulate the request posted on the previous comment, 
but can not find a problem. So I think we can close this issue here 
([~arafalov])

> SpellCheckResponse --.ClassCastException: 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List
> ---
>
> Key: SOLR-2025
> URL: https://issues.apache.org/jira/browse/SOLR-2025
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 1.4.1
>Reporter: Reuben Firmin
>
> org.apache.solr.client.solrj.SolrServerException: Error executing query
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95)
> at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:118)
> ...
> Caused by: java.lang.ClassCastException: 
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to java.util.List
> at 
> org.apache.solr.client.solrj.response.SpellCheckResponse$Suggestion.(SpellCheckResponse.java:107)
> at 
> org.apache.solr.client.solrj.response.SpellCheckResponse.(SpellCheckResponse.java:51)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.extractSpellCheckInfo(QueryResponse.java:125)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:115)
> at 
> org.apache.solr.client.solrj.response.QueryResponse.(QueryResponse.java:80)
> at 
> org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)



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

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

[jira] [Closed] (SOLR-2012) stats component, min/max on a field with no values

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-2012.
---
Resolution: Cannot Reproduce

> stats component, min/max on a field with no values
> --
>
> Key: SOLR-2012
> URL: https://issues.apache.org/jira/browse/SOLR-2012
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Jonathan Rochkind
>
> : 
> : When I use the stats component on a field that has no values in the result 
> set
> : (ie, stats.missing == rowCount), I'd expect that 'min'and 'max' would be
> : blank.
> : 
> : Instead, they seem to be the smallest and largest float values or something,
> : min = 1.7976931348623157E308, max = 4.9E-324 .
> : 
> : Is this a bug?
> off the top of my head it sounds like it ... would you mind opening a n 
> issue in Jira please?
> -Hoss



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

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

[jira] [Closed] (SOLR-2650) Empty docs array on response with grouping and result pagination

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-2650.
---
Resolution: Cannot Reproduce

> Empty docs array on response with grouping and result pagination
> 
>
> Key: SOLR-2650
> URL: https://issues.apache.org/jira/browse/SOLR-2650
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 3.3
>Reporter: Massimo Schiavon
> Attachments: grouping_patch.txt
>
>
> Requesting a certain number of rows and setting start parameter to a greater 
> value returns 0 results with grouping enabled.
> For example, requesting:
> http://localhost:8080/solr/web/select/?q=*:*=1=2
> (grouping and highlighting are enabled by default)
> I get this response:
> [...]
>   response: {
>   numFound: 117852
>   start: 2
>   docs: [ ]
>   }
>   highlighting: {
> 0938630598: {
>   title: [ "..." ]
>   content: [ "..." ]
> }
>   }
> [...]
> docs array is empty while the highlighted values of the document are present
> Debugging the request in
> org.apache.solr.search.Grouping.Command.createSimpleResponse() at row 534
> [...]
>  int len = Math.min(numGroups, docsGathered);
>   if (offset > len) {
> len = 0;
>   }
> [...]
> The initial vars values are:
> numGroups = 1
> docsGathered = 3
> offset = 2
> so after the execution len = 0
> I've tried commenting the if statement and this resolves the issue but could 
> introduce some other bugs.



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

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

[jira] [Closed] (SOLR-5931) solrcore.properties is not reloaded when core is reloaded

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-5931.
---
Resolution: Cannot Reproduce

> solrcore.properties is not reloaded when core is reloaded
> -
>
> Key: SOLR-5931
> URL: https://issues.apache.org/jira/browse/SOLR-5931
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 4.7
>Reporter: Gunnlaugur Thor Briem
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>
> When I change solrcore.properties for a core, and then reload the core, the 
> previous values of the properties in that file are still in effect. If I 
> *unload* the core and then add it back, in the “Core Admin” section of the 
> admin UI, then the changes in solrcore.properties do take effect.
> My specific test case is a DataImportHandler where {{db-data-config.xml}} 
> uses a property to decide which DB host to talk to:
> {code:xml}
>  url="jdbc:postgresql://${dbhost}/${solr.core.name}" .../>
> {code}
> When I change that {{dbhost}} property in {{solrcore.properties}} and reload 
> the core, the next dataimport operation still connects to the previous DB 
> host. Reloading the dataimport config does not help. I have to unload the 
> core (or fully restart the whole Solr) for the properties change to take 
> effect.



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

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

[jira] [Closed] (SOLR-5602) Solr DIH shows in-consistent status

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-5602.
---
Resolution: Cannot Reproduce

This case can't go anywhere until it is reproduced against the latest DIH with 
very specific instructions. If we get that, a case can be reopened or a new one 
created.

> Solr DIH shows in-consistent status
> ---
>
> Key: SOLR-5602
> URL: https://issues.apache.org/jira/browse/SOLR-5602
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.2
>Reporter: Liu Xiang
>
> I have one DIH index job which takes about 4 hr to finish.
> The job was launched at 11:28 am and completed at 15:10 pm.
> However, in DIH response, although "statusMessages" showed correct 
> information, "status" kept showing "busy" until 16:40 pm.
> After that, it became "idle". 
> This index job is one step of our data pipeline, we are using both "status" 
> and statusMessages" to decide should the job move to next step, I would like 
> to know the reason causing the in-consistent status.



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

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

[jira] [Closed] (SOLR-3509) Print support in Web UI

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-3509.
---
Resolution: Won't Fix

Printing Admin UI is a very edge-case. If somebody see the specific 
improvements requirements and wants to work on it, the case can be reopened or 
more-specific individual cases can be worked on.

> Print support in Web UI
> ---
>
> Key: SOLR-3509
> URL: https://issues.apache.org/jira/browse/SOLR-3509
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0-ALPHA
>Reporter: Lance Norskog
>Priority: Minor
> Attachments: NewUI_Print_Problems.pdf, SOLR-3509.patch, Solr Admin 
> (172.16.10.99).pdf
>
>
> Please try printing the various pages and decide if they need different 
> layouts or formatting. For example, it would help if all characters are in 
> black, not grey.
> I have attached a sample printout of the UI. 



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

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

[jira] [Closed] (SOLR-1488) autoCommit when idle

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-1488.
---
Resolution: Won't Fix

Other commit modes should be sufficient. Additionally, the commit properties 
could be changed via Config API to affect the Commit settings after indexing 
(though core will reload at that).

If there is a particular business need that cannot be addressed by other means, 
an issue can be reopened or a new one created.

> autoCommit when idle
> 
>
> Key: SOLR-1488
> URL: https://issues.apache.org/jira/browse/SOLR-1488
> Project: Solr
>  Issue Type: Improvement
>Reporter: Matt Weber
>Priority: Minor
> Attachments: SOLR-1488.patch
>
>
> Enable autoCommit to execute after a given amount of idle time (no documents 
> submitted).



--
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-1113) Error reports from ExtractingRequestHandler and Co do not indicate name of rejected documents

2016-10-08 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-1113:


Thanks!

> Error reports from ExtractingRequestHandler and Co do not indicate name of 
> rejected documents
> -
>
> Key: SOLR-1113
> URL: https://issues.apache.org/jira/browse/SOLR-1113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Reporter: Fergus McMenemie
>
> The ExtractingRequestHandler rejects documents that are larger than the 
> configured multipartUploadLimitInKB in solrconfig.xml. None of the generated 
> error messages indicate the name of the rejected document or provide any way 
> of identifying the rejected document. The failure to identify the rejected 
> document complicates the middleware used to look after indexes.
> Here is the trace produced by a recent version of trunk.
> {code}
> SEVERE: 
> org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException: the 
> request was rejected because its size (4585774) exceeds the configured 
> maximum (2097152)
>   at 
> org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.(FileUploadBase.java:914)
>   at 
> org.apache.commons.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:331)
>   at 
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:349)
>   at 
> org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
>   at 
> org.apache.solr.servlet.MultipartRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:343)
>   at 
> org.apache.solr.servlet.StandardRequestParser.parseParamsAndFillStreams(SolrRequestParsers.java:396)
>   at 
> org.apache.solr.servlet.SolrRequestParsers.parse(SolrRequestParsers.java:114)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> {code} 



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

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 459 - Still Failing!

2016-10-08 Thread Policeman Jenkins Server

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

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

Error Message:
QUERY FAILED: 
xpath=/response/arr[@name='fields']/lst/str[@name='name'][.='newTestFieldInt449']
  request=/schema/fields?wt=xml  response=

[jira] [Closed] (SOLR-1236) stop using strings for filepaths and start using File objects

2016-10-08 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch closed SOLR-1236.
---
Resolution: Implemented

This issue is done.

> stop using strings for filepaths and start using File objects
> -
>
> Key: SOLR-1236
> URL: https://issues.apache.org/jira/browse/SOLR-1236
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Priority: Trivial
>
> Catching up on my email after a long hiatus i notice SOLR-1213 and it 
> reminded me that the last time i was digging arround in the code i was 
> frustrated by lots of places in Solr where "String" instances to store a file 
> or directory paths and then manipulated with String operations.  I would be 
> nice to switch all of these member variables and and function params to use 
> genuine File objects to improve the code base readibility, and reduce the 
> likelyhood of OS variant bugs or nonsensical path operations.



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

41 matches

Mail list logo