[jira] [Comment Edited] (SOLR-6768) Creating examples fails when Solr runs in foreground mode

[ https://issues.apache.org/jira/browse/SOLR-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231848#comment-14231848 ] Timothy Potter edited comment on SOLR-6768 at 12/2/14 6:06 PM:

Re: [JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2267 - Failure

I’ll dig. On Tue, Dec 2, 2014 at 11:57 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2267/ 1 tests failed. FAILED: org.apache.lucene.spatial.prefix.DateNRStrategyTest.testContains {#9

[jira] [Commented] (LUCENE-6089) Tune CompressionMode.HIGH_COMPRESSION

[ https://issues.apache.org/jira/browse/LUCENE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231870#comment-14231870 ] ASF subversion and git services commented on LUCENE-6089: - Commit

[jira] [Commented] (LUCENE-6089) Tune CompressionMode.HIGH_COMPRESSION

[ https://issues.apache.org/jira/browse/LUCENE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231886#comment-14231886 ] ASF subversion and git services commented on LUCENE-6089: - Commit

[jira] [Resolved] (LUCENE-6089) Tune CompressionMode.HIGH_COMPRESSION

[ https://issues.apache.org/jira/browse/LUCENE-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-6089. - Resolution: Fixed Fix Version/s: Trunk 5.0 Tune

[jira] [Updated] (SOLR-6778) Dead end UX when following README

[ https://issues.apache.org/jira/browse/SOLR-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-6778: - Attachment: SOLR-6778.patch Here are some updates to the top-level README.txt However, we also

[jira] [Updated] (SOLR-4799) DIH: join=zipper aka merge join for nested EntityProcessors

[ https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-4799: --- Summary: DIH: join=zipper aka merge join for nested EntityProcessors (was:

[jira] [Commented] (SOLR-4799) DIH: join=zipper aka merge join for nested EntityProcessors

[ https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231942#comment-14231942 ] Mikhail Khludnev commented on SOLR-4799: [~noble.paul] do like this summary?

[jira] [Commented] (LUCENE-5873) AssertionError in ToChildBlockJoinScorer.advance

[ https://issues.apache.org/jira/browse/LUCENE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231947#comment-14231947 ] Mikhail Khludnev commented on LUCENE-5873: -- bq. ok [~jpountz], so what's about

Re: Why do we have a CoreAdminHandler#Load action?

Thanks Erick for clarifying that. So we have two options - On Tue, Dec 2, 2014 at 8:12 PM, Erick Erickson erickerick...@gmail.com wrote: Hmmm, this looks odd, indeed. Perhaps it was an incomplete attempt to fix up the fact that after you UNLOAD a core, it's not obvious that CREATE (or maybe

[jira] [Updated] (LUCENE-5914) More options for stored fields compression

[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5914: Attachment: LUCENE-5914.patch Here is a patch using the current stuff as proposed. I didn't

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_67) - Build # 4360 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4360/ Java: 32bit/jdk1.7.0_67 -client -XX:+UseParallelGC (asserts: false) 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.DistribCursorPagingTest Error Message: Could not remove the following files (in the

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

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/691/ 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: reload the collection time out:180s Stack Trace:

[jira] [Updated] (SOLR-6755) ClassCastException from CloudMLTQParserTest

[ https://issues.apache.org/jira/browse/SOLR-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-6755: --- Attachment: SOLR-6755.patch Adding a try catch block and logging to get a better idea of why this

[jira] [Commented] (SOLR-6780) some param values are duplicated when they override defaults, or are combined with appends values, or are an invariant that overrides a request param

[ https://issues.apache.org/jira/browse/SOLR-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232131#comment-14232131 ] ASF subversion and git services commented on SOLR-6780: --- Commit

[jira] [Resolved] (SOLR-6780) some param values are duplicated when they override defaults, or are combined with appends values, or are an invariant that overrides a request param

[ https://issues.apache.org/jira/browse/SOLR-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-6780. Resolution: Fixed some param values are duplicated when they override defaults, or are combined with

[jira] [Commented] (LUCENE-5914) More options for stored fields compression

[ https://issues.apache.org/jira/browse/LUCENE-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232189#comment-14232189 ] Adrien Grand commented on LUCENE-5914: -- This looks like a good start! Nice that we

[jira] [Commented] (SOLR-6755) ClassCastException from CloudMLTQParserTest

[ https://issues.apache.org/jira/browse/SOLR-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232191#comment-14232191 ] ASF subversion and git services commented on SOLR-6755: --- Commit

[jira] [Commented] (SOLR-6755) ClassCastException from CloudMLTQParserTest

[ https://issues.apache.org/jira/browse/SOLR-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232194#comment-14232194 ] ASF subversion and git services commented on SOLR-6755: --- Commit

Running tests incrementally based on changed files

Hi I am trying to setup a testing environment, which is running tests incrementally based on changed files, instead of running whole builds. I would like to try this for Lucene/Solr, hence I am trying to understand better the relationship between individual code changes and associated tests. For

[jira] [Commented] (LUCENE-4378) QueryParsers do not support negative boosts

[ https://issues.apache.org/jira/browse/LUCENE-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232255#comment-14232255 ] Endymion Dylan commented on LUCENE-4378: I +1 this feature. It's very very very

[jira] [Commented] (SOLR-6066) CollapsingQParserPlugin + Elevation does not respects fq (filter query)

[ https://issues.apache.org/jira/browse/SOLR-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232262#comment-14232262 ] David Boychuck commented on SOLR-6066: -- Hi Joel, Curious if this is still in the

Re: Running tests incrementally based on changed files

On 12/2/2014 3:31 PM, Michael Wechner wrote: I am trying to setup a testing environment, which is running tests incrementally based on changed files, instead of running whole builds. I would like to try this for Lucene/Solr, hence I am trying to understand better the relationship between

Re: Why do we have a CoreAdminHandler#Load action?

FWIW, LOAD has (as far as i understand) been basically deprecated since day #1. as described on the old wiki... /!\ not implemented yet! Use CREATE So far, no use cases have been presented for a LOAD command that aren't satisfied by using CREATE so it's doubtful that a separate LOAD

I think rejoin leader elections at the head isn't doing what it should

I'm particularly interested in Noble and Mark's comments... Let's say you have 5 nodes in n1, n2, n3, n4, n5. n1 is the leader, n2 watches n1 etc. Now I retryElection for n3 with joinAtHead=true. Both n2 and n3 are watching n1. So far, so good. My expectation is that deleting n1 would cause n3

Re: Why do we have a CoreAdminHandler#Load action?

Right, #2 here is just sugar over abusing the CREATE command for nice symmetry. I don't have much in the way of strong feelings here Erick On Tue, Dec 2, 2014 at 3:10 PM, Chris Hostetter hossman_luc...@fucit.org wrote: FWIW, LOAD has (as far as i understand) been basically deprecated

[jira] [Commented] (LUCENE-6086) Minor optimizations to the encoding of numerics in stored fields

[ https://issues.apache.org/jira/browse/LUCENE-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232406#comment-14232406 ] Ryan Ernst commented on LUCENE-6086: Very cool! Some thoughts: * Do we really need

Re: I think rejoin leader elections at the head isn't doing what it should

This is reminiscent of my conversation with Noble on this SOLR-6095 starting at this comment: https://issues.apache.org/jira/browse/SOLR-6095?focusedCommentId=14032386page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14032386 Unfortunately I dropped off following it

Re: I think rejoin leader elections at the head isn't doing what it should

Thanks! I somewhat remember seeing that conversation but I confess I didn't follow it that closely. I can't cope with looking at it any more tonight, but I'll check in the morning. The problem I see is I don't think there's any way, once a node is re-inserted in the queue, for another node to

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_20) - Build # 11701 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11701/ Java: 32bit/jdk1.8.0_20 -server -XX:+UseSerialGC (asserts: false) 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: Suite timeout exceeded (= 720 msec).

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b34) - Build # 11533 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11533/ Java: 32bit/jdk1.9.0-ea-b34 -server -XX:+UseSerialGC (asserts: true) 1 tests failed. FAILED: org.apache.lucene.analysis.icu.TestICUNormalizer2CharFilter.testRandomStrings Error Message: startOffset 97 expected:640 but was:639

[jira] [Created] (SOLR-6814) CoreAdminHandler#Load should call CREATE with minimal parameters

Varun Thacker created SOLR-6814: --- Summary: CoreAdminHandler#Load should call CREATE with minimal parameters Key: SOLR-6814 URL: https://issues.apache.org/jira/browse/SOLR-6814 Project: Solr

Re: Why do we have a CoreAdminHandler#Load action?

I created SOLR-6814 for this. On Wed, Dec 3, 2014 at 6:02 AM, Erick Erickson erickerick...@gmail.com wrote: Right, #2 here is just sugar over abusing the CREATE command for nice symmetry. I don't have much in the way of strong feelings here Erick On Tue, Dec 2, 2014 at 3:10 PM, Chris

[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[ https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232537#comment-14232537 ] Modassar Ather commented on LUCENE-5205: [~talli...@apache.org], yes the query

[jira] [Resolved] (SOLR-6674) Solr webapp deployment is very slow with jmx/ in solrconfig.xml

[ https://issues.apache.org/jira/browse/SOLR-6674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-6674. Resolution: Duplicate Dupe of SOLR-6675 Solr webapp deployment is very slow with jmx/ in

[jira] [Commented] (SOLR-6675) Solr webapp deployment is very slow with jmx/ in solrconfig.xml

[ https://issues.apache.org/jira/browse/SOLR-6675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232555#comment-14232555 ] Otis Gospodnetic commented on SOLR-6675: I've never heard or seen this before.

Re: solr client sdk's/libraries for native platforms

Ok, Done: https://wiki.apache.org/solr/IntegratingSolr Also: https://wiki.apache.org/solr/SolPython I am not sure what to do with the stuff at the bottom of the client list, though I've put the dates on it anyway. It's neither comprehensive nor representative and I don't understand the

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2270 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2270/ 1 tests failed. REGRESSION: org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.testDistribSearch Error Message: There are still nodes recoverying - waited for 30 seconds Stack Trace: java.lang.AssertionError:

Re: Running tests incrementally based on changed files

Hi Shawn Thanks very much for your feedback. Please see my comments inline below Am 03.12.14 um 00:10 schrieb Shawn Heisey: On 12/2/2014 3:31 PM, Michael Wechner wrote: I am trying to setup a testing environment, which is running tests incrementally based on changed files, instead of running

Re: Running tests incrementally based on changed files

A tangent, but a relevant one (to the issue of speed). Have you tried running the tests with Lucene/Solr code being in the RAM disk? I found that compiling source on RAMDisk is a lot faster than even with SSD drive. Must be just frequency of access. It might be the same with tests. Regards,

[jira] [Commented] (SOLR-6640) ChaosMonkeySafeLeaderTest failure with CorruptIndexException

[ https://issues.apache.org/jira/browse/SOLR-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232641#comment-14232641 ] Varun Thacker commented on SOLR-6640: - This is interesting - When I was running the

Re: Running tests incrementally based on changed files

On 12/2/2014 10:53 PM, Alexandre Rafalovitch wrote: A tangent, but a relevant one (to the issue of speed). Have you tried running the tests with Lucene/Solr code being in the RAM disk? I found that compiling source on RAMDisk is a lot faster than even with SSD drive. Must be just frequency

Re: Running tests incrementally based on changed files

Am 03.12.14 um 06:53 schrieb Alexandre Rafalovitch: A tangent, but a relevant one (to the issue of speed). Have you tried running the tests with Lucene/Solr code being in the RAM disk? no, but that's a good idea re speed. I found that compiling source on RAMDisk is a lot faster than even

[jira] [Commented] (LUCENE-5929) Standard highlighting doesn't work for ToParentBlockJoinQuery

[ https://issues.apache.org/jira/browse/LUCENE-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232652#comment-14232652 ] Julie Tibshirani commented on LUCENE-5929: -- No problem, thank you Michael!

Re: Running tests incrementally based on changed files

On 12/2/2014 10:47 PM, Michael Wechner wrote: I think you are right that in certain cases, like for example in the case of CompressingStoredFieldsFormat it makes a lot of sense to run the entire test suit (even multiple times considering randomization), but I would argue that there are

<    1   2