[CVE-2020-13957] The checks added to unauthenticated configset uploads in Apache Solr can be circumvented

[Tomas Fernandez Lobbe]

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
6.6.0 to 6.6.5
7.0.0 to 7.7.3
8.0.0 to 8.6.2

Description:
Solr prevents some features considered dangerous (which could be used for
remote code execution) to be configured in a ConfigSet that's uploaded via
API without authentication/authorization. The checks in place to prevent
such features can be circumvented by using a combination of UPLOAD/CREATE
actions.

Mitigation:
Any of the following are enough to prevent this vulnerability:
* Disable UPLOAD command in ConfigSets API if not used by setting the
system property: "configset.upload.enabled" to "false" [1]
* Use Authentication/Authorization and make sure unknown requests aren't
allowed [2]
* Upgrade to Solr 8.6.3 or greater.
* If upgrading is not an option, consider applying the patch in SOLR-14663
([3])
* No Solr API, including the Admin UI, is designed to be exposed to
non-trusted parties. Tune your firewall so that only trusted computers and
people are allowed access

Credit:
Tomás Fernández Löbbe, András Salamon

References:
[1] https://lucene.apache.org/solr/guide/8_6/configsets-api.html
[2]
https://lucene.apache.org/solr/guide/8_6/authentication-and-authorization-plugins.html
[3] https://issues.apache.org/jira/browse/SOLR-14663
[4] https://issues.apache.org/jira/browse/SOLR-14925
[5] https://wiki.apache.org/solr/SolrSecurity

Re: Gradle build

[Tomas Fernandez Lobbe]

+1 to option 2 to begin with. I don’t know if we need to wait for a major 
release for this change, but I think it may be easier to iterate while it’s 
only in master for a while.

> On Nov 7, 2019, at 2:41 PM, Adrien Grand  wrote:
> 
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
> 
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett  
> wrote:
>> 
>> I’m fine with Option 2.
>> 
>> Putting my project manager hat on, I’d really like to see a central list or 
>> Jira issues of the things we want to make sure to do before we can turn off 
>> Ant. The list/sub-tasks could be compiled after it’s merged to master, but 
>> it would be nice if we could approach this in a coordinated way so we’re all 
>> able to figure out quickly what remains - I think we’ll have a higher chance 
>> of faster success that way. Hopefully also people would sign up for the 
>> things that they will volunteer to drive to completion instead of hanging 
>> back because they aren’t sure what needs to be done.
>> 
>> Dawid and I worked on the Ref Guide transition to Gradle in a separate 
>> branch and it’s either finished or very close to it IMO. It includes the PR 
>> I put up last night to remove the PDF build tasks. I just need to merge it 
>> into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to 
>> do by tomorrow.
>> 
>> Cassandra
>> On Nov 6, 2019, 3:07 PM -0600, David Smiley , 
>> wrote:
>> 
>> Option 2.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson  
>> wrote:
>>> 
>>> All:
>>> 
>>> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive 
>>> here is if this was pushed, even in its current incomplete state, people 
>>> would have an easier time contributing to the effort. Of course this means 
>>> I would be asking people to use the gradle build at least on master if at 
>>> all possible.
>>> 
>>> There are several assumptions I’m making here:
>>> 
>>> - we can keep running the Ant build as long as necessary. Ant would be our 
>>> primary build process. The purpose of pushing the current Gradle effort is 
>>> to make it easier for others to contribute and “just try it”.
>>> 
>>> - There are no conflicts between the Gradle and Ant builds, so we can 
>>> continue to use Ant as necessary until we make the switch.
>>> 
>>> - people will commit up front to putting some effort into this. I flat 
>>> guarantee I won’t carry the load alone. If nobody else steps up, I’ll table 
>>> it. I will volunteer to push fixes from non-committers.
>>> — Yes, people can do this already with the gradle_8 branch, it’d just be 
>>> easier if it was already in the pull.
>>> 
>>> - moving to Gradle as our primary workflow won’t happen until we work out 
>>> some of the kinks, things like.
>>> — running on Jenkins.
>>> — Getting the equivalent of “ant server dist” to run.
>>> — Getting the ref guide built.
>>> — I’m sure other things will crop up.
>>> 
>>> 
>>> So there are several options, please let me know which one you prefer:
>>> 
>>> 1. do nothing. People can check out the gradle_8 build and work on it. 
>>> There has been some of this so far, many thanks.
>>> 
>>> 2. merge it into master only. TBD is when we take Ant out of master.
>>> 
>>> 3. merge into both master and 8x. Assuming we can continue to use both, I’m 
>>> not sure what advantage there is to merging into 8x. This seems like 
>>> something that should come along with a major version release.
>>> 
>>> 4. wait until it’s feature-complete. Based on the evidence so far, this may 
>>> be a long time coming.
>>> 
>>> Also, the timing is fungible. I don’t see a downside as long as we can 
>>> continue to build with Ant. I certainly _do_ see a downside if we have to 
>>> do everything Ant does immediately after pushing to whatever branches.
>>> 
>>> Erick
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[SECURITY] CVE-2019-12401: XML Bomb in Apache Solr versions prior to 5.0

[Tomas Fernandez Lobbe]

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:
1.3.0 to 1.4.1
3.1.0 to 3.6.2
4.0.0 to 4.10.4

Description: Solr versions prior to 5.0.0 are vulnerable to an XML resource
consumption attack (a.k.a. Lol Bomb) via it’s update handler. By leveraging
XML DOCTYPE and ENTITY type elements, the attacker can create a pattern
that will expand when the server parses the XML causing OOMs

Mitigation:
* Upgrade to Apache Solr 5.0 or later.
* Ensure your network settings are configured so that only trusted traffic
is allowed to post documents to the running Solr instances.

Credit: Matei "Mal" Badanoiu

References:
[1] https://issues.apache.org/jira/browse/SOLR-13750
[2] https://wiki.apache.org/solr/SolrSecurity

CVE-2019-0192 Deserialization of untrusted data via jmx.serviceUrl in Apache Solr

[Tomas Fernandez Lobbe]

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
5.0.0 to 5.5.5
6.0.0 to 6.6.5

Description:
ConfigAPI allows to configure Solr's JMX server via an HTTP POST request.
By pointing it to a malicious RMI server, an attacker could take advantage
of Solr's unsafe deserialization to trigger remote code execution on the
Solr side.

Mitigation:
Any of the following are enough to prevent this vulnerability:
* Upgrade to Apache Solr 7.0 or later.
* Disable the ConfigAPI if not in use, by running Solr with the system
property “disable.configEdit=true”
* If upgrading or disabling the Config API are not viable options, apply
patch in [1] and re-compile Solr.
* Ensure your network settings are configured so that only trusted traffic
is allowed to ingress/egress your hosts running Solr.

Credit:
Michael Stepankin

References:
[1] https://issues.apache.org/jira/browse/SOLR-13301
[2] https://wiki.apache.org/solr/SolrSecurity

[SECURITY] CVE-2017-3164 SSRF issue in Apache Solr

[Tomas Fernandez Lobbe]

CVE-2017-3164 SSRF issue in Apache Solr

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Solr versions from 1.3 to 7.6.0

Description:
The "shards" parameter does not have a corresponding whitelist mechanism,
so it can request any URL.

Mitigation:
Upgrade to Apache Solr 7.7.0 or later.
Ensure your network settings are configured so that only trusted traffic is
allowed to ingress/egress your hosts running Solr.

Credit:
dk from Chaitin Tech

References:
https://issues.apache.org/jira/browse/SOLR-12770
https://wiki.apache.org/solr/SolrSecurity

Re: [DISCUSS] Solr separate deprecation log

[Tomas Fernandez Lobbe]

+1 Sounds like a good a idea to me.

> On Nov 8, 2018, at 5:06 AM, Jan Høydahl  wrote:
> 
> Hi,
> 
> When instructing people in what to do before upgrading to a new version, we 
> often tell them to check for deprecation log messages and fix those before 
> upgrading. Normally you'll see the most important logs as WARN level in the 
> Admin UI log tab just after startup and first use. But I'm wondering if it 
> also makes sense to introduce a separate DeprecationLogger.log(foo) that is 
> configured in log4j2.xml to log to a separate logs/deprecation.log to make it 
> easier to check this from the command line. If the file is non-empty you have 
> work to do :)
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: VOTE: Apache Solr Reference Guide for Solr 7.3 RC1

[Tomas Fernandez Lobbe]

+1

> On Apr 3, 2018, at 12:45 PM, Varun Thacker  wrote:
> 
> +1
> 
> On Tue, Apr 3, 2018 at 10:47 AM, Steve Rowe  > wrote:
> +1
> 
> --
> Steve
> www.lucidworks.com 
> 
> > On Apr 3, 2018, at 10:06 AM, Mikhail Khludnev  > > wrote:
> >
> > I've looked through recent changes in PDF. It seems good.
> >
> > On Tue, Apr 3, 2018 at 4:32 PM, Cassandra Targett  > > wrote:
> > Reminder about this.
> >
> > It looks like the Lucene/Solr release vote is going to pass, so we could 
> > have both released at about the same time.
> >
> > Thanks,
> > Cassandra
> >
> > On Thu, Mar 29, 2018 at 10:49 AM, Cassandra Targett  > > wrote:
> > Please vote to release the Apache Solr Reference Guide for Solr 7.3.
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.3-RC1/
> >  
> > 
> >
> > $ cat apache-solr-ref-guide-7.3.pdf.sha1
> > 151f06d920d1ac41564f3c0ddabae3c2c36b6892  apache-solr-ref-guide-7.3.pdf
> >
> > The HTML version has also been uploaded to the website:
> > https://lucene.apache.org/solr/guide/7_3/ 
> > 
> >
> > Here's my +1.
> >
> > If it happens that this vote passes before the vote for the final 
> > Lucene/Solr RC is complete, I'll hold release/announcement of the Ref Guide 
> > until the vote is complete and the release steps are finished.
> >
> > Thanks,
> > Cassandra
> >
> >
> >
> >
> > --
> > Sincerely yours
> > Mikhail Khludnev
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 

Re: Welcome Cao Mạnh Đạt to the PMC

[Tomas Fernandez Lobbe]

Welcome Đạt!

> On Apr 2, 2018, at 2:59 PM, Christian Moen  wrote:
> 
> Congrats, Đạt!
> 
> On Mon, Apr 2, 2018 at 11:48 PM Varun Thacker  > wrote:
> Congratulations and welcome Dat!
> 
> On Mon, Apr 2, 2018 at 12:50 PM, Adrien Grand  > wrote:
> Fixing the subject of the email.
> 
> Le lun. 2 avr. 2018 à 21:48, Adrien Grand  > a écrit :
> I am pleased to announce that Cao Mạnh Đạt has accepted the PMC's invitation 
> to join.
> 
> Welcome Đạt!
> 

Re: [VOTE] Release Lucene/Solr 7.3.0 RC2

[Tomas Fernandez Lobbe]

+1

SUCCESS! [0:53:45.634419]

> On Mar 30, 2018, at 12:36 AM, Dawid Weiss  wrote:
> 
> +1 SUCCESS! [1:19:17.302674]
> 
> D.
> 
> On Fri, Mar 30, 2018 at 9:27 AM, Adrien Grand  wrote:
>> +1 SUCCESS! [2:09:23.584262]
>> 
>> I added the missing 7.2.1 version constant in case we respin.
>> 
>> Le jeu. 29 mars 2018 à 19:12, Steve Rowe  a écrit :
>>> 
>>> (resending because I replied to the wrong thread earlier)
>>> 
>>> +1
>>> 
>>> Docs, changes and javadocs look good.
>>> 
>>> Smoke tester says: SUCCESS! [0:35:05.242678]
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Mar 28, 2018, at 1:11 PM, Alan Woodward  wrote:
 
 Please vote for release candidate 2 for Lucene/Solr 7.3.0
 
 The artefacts can be downloaded from:
 
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.0-RC2-rev98a6b3d642928b1ac9076c6c5a369472581f7633
 
 You can run the smoke tester directly with this command:
 python3 -u dev-tools/scripts/smokeTestRelease.py
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.0-RC2-rev98a6b3d642928b1ac9076c6c5a369472581f7633
 
 Here’s my +1
 SUCCESS! [1:08:28.045253]
 
 
 Note that this vote will be open a little longer than usual as it’s a
 Bank Holiday weekend in the UK.  If there are no -1s, the vote will close 
 on
 Tuesday April 3rd.
>>> 
>>> 
>>> -
>>> 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
> 


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

Re: TestLTRReRankingPipeline.testDifferentTopN fails 100% on master / branch_7x

[Tomas Fernandez Lobbe]

Lets fix or move to @AwaitsFix for cases like these. I believe Erick just 
wanted to verify that these @AwaitFix were still broken when he moved them to 
@BadApple, but the idea was to put them back in @AwaitsFix if they prove to be 
effectively broken. 

I’m also +1 to reopen the test-specific Jira issue in such cases as other 
people suggested in SOLR-12028.

Tomás

> On Mar 15, 2018, at 2:13 AM, Andrzej Białecki  wrote:
> 
> Hi,
> 
> This test is marked BadApple but fails 100% all the time in my local builds 
> and on jenkins. This is not what a bad apple means … it’s simply broken and 
> needs to be fixed.
> 
> The issue that changed AwaitsFix to BadApple is SOLR-11134 (Apache Jira seems 
> to have some problems at the moment - I can’t reopen the issue).
> 
> I propose to do one of the following:
> 
> * fix it :)
> 
> * change the annotation back to AwaitsFix (assuming that at some point some 
> gentle soul will write a script to run & report AwaitsFix tests so that they 
> are not simply ignored)
> 
> * leave it as is (and pretend it’s ok …)
> 
> —
> 
> Andrzej Białecki
> 

Re: Code Reviews

[Tomas Fernandez Lobbe]

> Like Dawid I hope we won't add strict requirements to get changes reviewed 
> before merging but I do agree with the general sentiment that reviews are 
> helpful and improve code quality.
This seems to be what the majority thinks and I see the point, I’m concerned of 
this myself. I’m just not sure how to encourage people to submit for review and 
review other peoples more since the option is there now and is not very 
frequently used. I’m open to suggestions if anyone has ideas. 

> I really appreciate getting feedback on patches that I upload, including 
> negative feedback and I don't mind being pinged on issues if anyone thinks I 
> might have valuable feedback to give.
Exactly, same here. The times I got my patches reviewed and I got very valuable 
feedback, including someone fixing something broken in my patch.

I encourage people to go and review some random commits and see if they could 
have given any valuable feedback. Someone could tell me “you can go, review, 
and create a new Jira with your proposed changes”, but that doesn’t happen 
usually, so back to my point.


> On Feb 28, 2018, at 5:11 PM, Adrien Grand  wrote:
> 
> Like Dawid I hope we won't add strict requirements to get changes reviewed 
> before merging but I do agree with the general sentiment that reviews are 
> helpful and improve code quality. I really appreciate getting feedback on 
> patches that I upload, including negative feedback and I don't mind being 
> pinged on issues if anyone thinks I might have valuable feedback to give.
> 
> I didn't know Solr had a CTR policy. I understand CTR and RTC have pros and 
> cons but since there seems to be agreement that we want more changes to be 
> reviewed I think RTC is better at encouraging a review culture: as a reviewer 
> it's easier to recommend that the change should be done in a totally 
> different way if that is what you think, and you also feel more useful since 
> someone considered that the change needs your pair of eyes before being 
> merged.
> 
> Le mer. 28 févr. 2018 à 21:07, Cassandra Targett  > a écrit :
> On Wed, Feb 28, 2018 at 1:58 PM, Shawn Heisey  > wrote:
> 
> I notice in ZK issues that projects associated with Hadoop have an
> *automatic* machine-generated QA check whenever a patch is submitted on
> those projects.  This obviously is not the same as a real review by a
> person, but the info it outputs seems useful.
> 
> 
> 
> This is what SOLR-10912 intends to achieve. 
> 

Re: Code Reviews

[Tomas Fernandez Lobbe]

I’m not sure how CTR was put in place either, but it was done 10+ years ago, 
when Solr had less than 1/10 of the committers it has now and who knows how 
many less production deployments/users. Now Solr is a completely different 
project than back then, and what was the correct process then may not be the 
correct process now. I’m happy to trade some development speed for code quality.

I think just saying “anyone can ask for a review” is not going to be good 
enough, this is the case right now, and it rarely happen. 

Tomás

> On Feb 28, 2018, at 10:17 AM, Joel Bernstein  wrote:
> 
> I agree that code reviews would be a good idea. But to require code reviews 
> before committing would be a big change in practice for the Solr committers. 
> I'm not sure how the commit, then review policy was put in place or what it 
> would mean to change that. Also I would probably personally vote against a 
> change to the commit and the review policy.
> 
> But, I would be open to encouraging a culture of code review like there is in 
> Lucene.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
> 
> On Wed, Feb 28, 2018 at 12:59 PM, Tomas Fernandez Lobbe  <mailto:tflo...@apple.com>> wrote:
> In an effort to improve code quality, I’d like to suggest that we start 
> requiring code review to non-trivial patches. Not sure if/how other open 
> source projects are doing code reviews, but I’ve been using it in internal 
> projects for many years and it’s a great way to catch bugs early, some of 
> them very difficult to catch in unit tests, like “You are breaking API 
> compatibility with this change”, or “you are swallowing 
> InterruptedExceptions”, etc. It is also a great way to standardize a bit more 
> our code base and to encourage community members to review and learn then 
> code.
> In Lucene-land, this is already a common practice but on the Solr side is 
> rare to see. It is common on Solr that committer A doesn’t know much about 
> component X, so reviewing that may sound useless, but even in that case you 
> can provide feedback on the code itself being added (and in the meantime 
> learn something about component X).
> 
> What do people think about it?
> 
> Regarding tools to do it, I’m open to suggestions. I really like Github PRs, 
> that now are easy to integrate with Jira and you can create PRs from forks or 
> even from two existing branches of the official repo. Also, since people is 
> really familiar with them, I expect to encourage reviewers by using them.
> 
> Tomás
> 

Code Reviews

[Tomas Fernandez Lobbe]

In an effort to improve code quality, I’d like to suggest that we start 
requiring code review to non-trivial patches. Not sure if/how other open source 
projects are doing code reviews, but I’ve been using it in internal projects 
for many years and it’s a great way to catch bugs early, some of them very 
difficult to catch in unit tests, like “You are breaking API compatibility with 
this change”, or “you are swallowing InterruptedExceptions”, etc. It is also a 
great way to standardize a bit more our code base and to encourage community 
members to review and learn then code.
In Lucene-land, this is already a common practice but on the Solr side is rare 
to see. It is common on Solr that committer A doesn’t know much about component 
X, so reviewing that may sound useless, but even in that case you can provide 
feedback on the code itself being added (and in the meantime learn something 
about component X).

What do people think about it?

Regarding tools to do it, I’m open to suggestions. I really like Github PRs, 
that now are easy to integrate with Jira and you can create PRs from forks or 
even from two existing branches of the official repo. Also, since people is 
really familiar with them, I expect to encourage reviewers by using them.

Tomás

Re: Need to install Solr in Tomcat in Eclipse

[Tomas Fernandez Lobbe]

Hi Mayank, 
I haven’t tried it yet, but a user proposed a patch to add Eclipse launchers. 
See https://issues.apache.org/jira/browse/SOLR-11331. It’s not running Tomcat 
though, It uses the Jetty jars that are shipped with Solr. 
Note that, for creating the Eclipse project and for running unit tests you only 
need to `ant eclipse`, and then import as existing project to Eclipse, as 
described here: https://wiki.apache.org/solr/HowToConfigureEclipse.

I hope it helps. 

Tomás

> On Feb 9, 2018, at 3:21 AM, Mayank Kumar  wrote:
> 
> Hi,
> 
> I am Mayank and just wanted to contribute to Apache Solr.
> 
> I want to deploy the solr application in Apache tomcat in Eclipse so that I 
> will be able to debug it.
> 
> Can anybody help me in doing the same.
> 
> 
> Thank you,
> Mayank
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Welcome Ignacio Vera as Lucene/Solr committer

[Tomas Fernandez Lobbe]

Welcome Ignacio!

> On Jan 11, 2018, at 10:50 AM, Joel Bernstein  wrote:
> 
> Welcome Ignacio!
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> On Thu, Jan 11, 2018 at 1:45 PM, Ahmet Arslan  > wrote:
> 
> 
> Congratulations Ignacio!
> 
> Ahmet
> 
> 
> 
> 
> On Thursday, January 11, 2018, 9:43:50 PM GMT+3, Martin Gainty 
> mailto:mgai...@hotmail.com>> wrote:
> 
> 
> 
> 
> 
> 
> 
> ¡Bienvendos Ignacio!
> 
> 
> 
> 
> Martín
> __ 
> 
> 
> 
> 
> From: Erick Erickson  >
> Sent: Thursday, January 11, 2018 12:39 PM
> To: dev@lucene.apache.org 
> Subject: Re: Welcome Ignacio Vera as Lucene/Solr committer
>  
> 
> 
> 
> Welcome Ignacio!
> 
> 
> 
> 
> On Thu, Jan 11, 2018 at 9:09 AM, Karl Wright   > wrote:
> 
> >  
> > Welcome, Ignacio!
> > Karl
> >
> >
> >  
> >  
> >
> >
> > On Thu, Jan 11, 2018 at 11:46 AM, Steve Rowe   > > wrote:
> >
> >>  Congrats and welcome Ignacio!
> >>
> >> --
> >> Steve
> >> www.lucidworks.com 
> >>
> >>  
> >>
> >>> On Jan 11, 2018, at 11:35 AM, Adrien Grand  >>> > wrote:
> >>>
> >>> Hi all,
> >>>
> >>> Please join me in welcoming Ignacio Vera as the latest Lucene/Solr 
> >>> committer.
> >>> Ignacio, it's tradition for you to introduce yourself with a brief bio.
> >>>
> >>> Congratulations and Welcome!
> >>
> >>
> >>
> >>
> >> -- -- -
> >> To unsubscribe, e-mail:  dev-unsubscribe@lucene.apache. org
> >> For additional commands, e-mail:  dev-h...@lucene.apache.org 
> >> 
> >>
> >>
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 

Re: [VOTE] Release Lucene/Solr 7.2.1 RC1

[Tomas Fernandez Lobbe]

+1

SUCCESS! [1:04:34.912689]

> On Jan 10, 2018, at 8:01 AM, Alan Woodward  wrote:
> 
> +1
> 
> SUCCESS! [1:43:16.772919]
> 
> I need to get a new test machine...
> 
>> On 10 Jan 2018, at 09:51, Dawid Weiss  wrote:
>> 
>> +1
>> 
>> SUCCESS! [1:31:30.029815]
>> 
>> Dawid
>> 
>> On Wed, Jan 10, 2018 at 10:46 AM, Shalin Shekhar Mangar
>>  wrote:
>>> +1
>>> 
>>> SUCCESS! [1:13:22.042124]
>>> 
>>> On Wed, Jan 10, 2018 at 8:00 AM, jim ferenczi  
>>> wrote:
 Please vote for release candidate 1 for Lucene/Solr 7.2.1
 
 The artifacts can be downloaded from:
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.1-RC1-revb2b6438b37073bee1fca40374e85bf91aa457c0b
 
 You can run the smoke tester directly with this command:
 
 python3 -u dev-tools/scripts/smokeTestRelease.py \
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.2.1-RC1-revb2b6438b37073bee1fca40374e85bf91aa457c0b
 
 Here's my +1
 SUCCESS! [0:38:10.689623]
>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> Shalin Shekhar Mangar.
>>> 
>>> -
>>> 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
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Welcome Karl Wright to the PMC

[Tomas Fernandez Lobbe]

Welcome Karl!

Sent from my iPhone

> On Dec 29, 2017, at 11:56 AM, Varun Thacker  wrote:
> 
> Welcome Karl!
> 
>> On Fri, Dec 29, 2017 at 7:13 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>>  wrote:
>> Welcome Karl!
>> 
>> From: dev@lucene.apache.org At: 12/28/17 14:09:09
>> To:  dev@lucene.apache.org
>> Subject: Welcome Karl Wright to the PMC
>> I am pleased to announce that Karl Wright has accepted the PMC's invitation 
>> to join.
>> 
>> Welcome Karl!
> 

Re: Welcome Dennis Gove to the PMC

[Tomas Fernandez Lobbe]

Welcome Dennis!!

Sent from my iPhone

> On Dec 29, 2017, at 7:31 PM, Dennis Gove  wrote:
> 
> Thanks everyone!
> 
>> On Thu, Dec 28, 2017 at 4:32 PM, Michael McCandless 
>>  wrote:
>> Welcome Dennis!
>> 
>> Mike McCandless
>> 
>> http://blog.mikemccandless.com
>> 
>>> On Tue, Dec 26, 2017 at 8:12 AM, Joel Bernstein  wrote:
>>> I am pleased to announce that Dennis Gove has accepted the PMC's invitation 
>>> to join.
>>> 
>>> Welcome Dennis!
>> 
> 

Re: VOTE: Release Apache Solr Reference Guide for Solr 7.2

[Tomas Fernandez Lobbe]

+1

> On Dec 18, 2017, at 1:18 PM, Alexandre Rafalovitch  wrote:
> 
> Actually,
> 
> I think it would have to be one of the new semi-interactive manuals
> both O'Reilly and Mannings are building platforms for. Or a boxset of
> end-to-end Solr examples for interesting datasets. I think a lack of
> public pre-populated Solr play instances is a limiting factors.
> 
> Regards,
>   Alex.
> 
> 
> On 18 December 2017 at 16:07, David Smiley  wrote:
>> On Mon, Dec 18, 2017 at 2:49 PM Alexandre Rafalovitch 
>> wrote:
>>> 
>>> 1100+ pages.. This may well be why we don't have any new Solr
>>> books. Hard to see the angle to compete with the documentation. :-)
>> 
>> 
>> LOL right.  If I were ever forced to write another Solr book (and it would
>> be at gunpoint and with my wife leaving me) I think the book should be way
>> more of a tutorial (or multiple tutorials) + guide and/or "cookbook" style.
>> It's no longer realistic to try to document everything.
>> 
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Welcome Jim Ferenczi to the PMC

[Tomas Fernandez Lobbe]

Welcome Jim!

> On Dec 20, 2017, at 10:13 AM, Shalin Shekhar Mangar  
> wrote:
> 
> Welcome Jim!
> 
> On Wed, Dec 20, 2017 at 11:28 PM, jim ferenczi  wrote:
>> Thanks and happy holidays to all of you !
>> 
>> Le 20 déc. 2017 17:24, "Shai Erera"  a écrit :
>>> 
>>> Welcome!
>>> 
>>> On Wed, Dec 20, 2017 at 6:07 PM Erick Erickson 
>>> wrote:
 
 Welcome!
 
 On Wed, Dec 20, 2017 at 7:23 AM, Joel Bernstein 
 wrote:
> Welcome Jim!
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> On Wed, Dec 20, 2017 at 10:12 AM, David Smiley
> 
> wrote:
>> 
>> Welcome Jim!
>> 
>> On Wed, Dec 20, 2017 at 9:28 AM Steve Rowe  wrote:
>>> 
>>> Congrats and welcome Jim!
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
 On Dec 20, 2017, at 5:18 AM, Adrien Grand 
 wrote:
 
 I am pleased to announce that Jim Ferenczi has accepted the PMC's
 invitation to join.
 
 Welcome Jim!
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
> 
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>> 
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: VOTE: Solr Reference Guide for 7.1 (RC1)

[Tomas Fernandez Lobbe]

+1

> On Oct 30, 2017, at 2:07 PM, Anshum Gupta  wrote:
> 
> I didn’t spend as much time I would’ve liked but overall it looks good to me.
> 
> +1.
> 
> Thanks for doing this Cassandra (and everyone else) !
> 
> -Anshum
> 
> 
> 
>> On Oct 27, 2017, at 11:59 AM, Cassandra Targett > > wrote:
>> 
>> Please vote to release the Solr Reference Guide for Solr 7.1.
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.1-RC1/
>>  
>> 
>> 
>> $ cat apache-solr-ref-guide-7.1.pdf.sha1
>> 4d43f5511ef5645cd344efabab5f04a9db3ce09b  apache-solr-ref-guide-7.1.pdf
>> 
>> The HTML version has also been uploaded:
>> https://lucene.apache.org/solr/guide/7_1/
>> 
>> Here's my +1.
>> 
>> Cassandra
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 

Re: Congratulations to the new Lucene/Solr PMC Chair, Adrien Grand

[Tomas Fernandez Lobbe]

Congratulations Adrien!

> On Oct 19, 2017, at 10:51 AM, Martin Gainty  wrote:
> 
> Félicitations Adrien!
> 
> Martin 
> __ 
> 
> From: ansh...@apple.com  on behalf of Anshum Gupta 
> 
> Sent: Thursday, October 19, 2017 11:52 AM
> To: dev@lucene.apache.org
> Subject: Re: Congratulations to the new Lucene/Solr PMC Chair, Adrien Grand
>  
> Congratulations Adrien!
> 
> -Anshum
> 
> 
> 
>> On Oct 19, 2017, at 12:19 AM, Tommaso Teofili > > wrote:
>> 
>> Once a year the Lucene PMC rotates the PMC chair and Apache Vice President 
>> position.
>> This year we have nominated and elected Adrien Grand as the chair and today 
>> the board just approved it, so now it's official.
>> 
>> Congratulations Adrien!
>> Regards,
>> Tommaso

Re: Synchronization in SolrClientCache looks wrong

[Tomas Fernandez Lobbe]

The synchronized at the method level blocks any other call to any synchronized 
method on the same object, so this is correct.

> On Aug 10, 2017, at 4:34 PM, Erick Erickson  wrote:
> 
> And if it's impossible for more than one thread to be using the class,
> why bother to synchronize?
> 
> Or am I misreading things totally?
> 
> On Thu, Aug 10, 2017 at 4:21 PM, Erick Erickson  
> wrote:
>> What prevents one thread from calling a get operation while another is
>> closing out from underneath? Or is it impossible that more than one thread
>> have access to this object?
>> 
>> 
>> On Aug 10, 2017 2:32 PM, "Joel Bernstein"  wrote:
>> 
>> Just took a look at the class and it seems OK. All methods are synchronized,
>> so we shouldn't have any race conditions. What are your concerns?
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>> 
>> On Thu, Aug 10, 2017 at 4:32 PM, Tomas Fernandez Lobbe 
>> wrote:
>>> 
>>> You mean, remove the synchronization from the method and synchronize the
>>> whole thing on solrClients? How is that different?
>>> 
>>> 
>>>> On Aug 10, 2017, at 12:48 PM, Erick Erickson 
>>>> wrote:
>>>> 
>>>> All the methods are synchronized, but they all operate on the
>>>> 
>>>> private final Map solrClients;
>>>> 
>>>> member variable, including code like this:
>>>> 
>>>> if (solrClients.containsKey(host)) {
>>>> client = (HttpSolrClient) solrClients.get(host);
>>>> }
>>>> 
>>>> But the close method goes through the list closing all the entries in
>>>> solrClients. Seems like these ought to be synchronized blocks on
>>>> solrClients
>>>> 
>>>> I have another place that needs updating too that I was investigating
>>>> when I saw this so I'll do them both at once if so (SOLR-11224)
>>>> 
>>>> Erick
>>>> 
>>>> -
>>>> 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
>>> 
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Synchronization in SolrClientCache looks wrong

[Tomas Fernandez Lobbe]

You mean, remove the synchronization from the method and synchronize the whole 
thing on solrClients? How is that different?


> On Aug 10, 2017, at 12:48 PM, Erick Erickson  wrote:
> 
> All the methods are synchronized, but they all operate on the
> 
> private final Map solrClients;
> 
> member variable, including code like this:
> 
> if (solrClients.containsKey(host)) {
>  client = (HttpSolrClient) solrClients.get(host);
> }
> 
> But the close method goes through the list closing all the entries in
> solrClients. Seems like these ought to be synchronized blocks on
> solrClients
> 
> I have another place that needs updating too that I was investigating
> when I saw this so I'll do them both at once if so (SOLR-11224)
> 
> Erick
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: 7.0 Release Update

[Tomas Fernandez Lobbe]

Lets fix it before releasing. I’d hate to release with a known critical bug.

> On Aug 10, 2017, at 12:54 PM, Anshum Gupta  wrote:
> 
> Hi Ab,
> 
> How quickly are we talking about? If you suggest, we could wait, depending 
> upon the impact, and the time required to fix it.
> 
> Anshum
> 
> On Thu, Aug 10, 2017 at 12:28 PM Andrzej Białecki 
> mailto:andrzej.biale...@lucidworks.com>> 
> wrote:
> I just discovered SOLR-11221, which basically breaks JMX monitoring. We could 
> either release with “known issues” and then quickly do 7.0.1, or wait until 
> it’s fixed.
> 
>> On 10 Aug 2017, at 18:55, Mark Miller > > wrote:
>> 
>> I'll generate a test report for the 7.0 branch tonight so we can evaluate 
>> that for an rc as well.
>> 
>> - Mark
>> 
>> On Mon, Aug 7, 2017 at 1:32 PM Anshum Gupta > > wrote:
>> Good news! 
>> 
>> I don't see any 'blockers' for 7.0 anymore, which means, after giving 
>> Jenkins a couple of days, I'll cut out an RC. I intend to do this on 
>> Wednesday/Thursday, unless a blocker comes up, which I hope shouldn't be the 
>> case.
>> 
>> Anshum
>> 
>> 
>> On Tue, Jul 25, 2017 at 4:02 PM Steve Rowe > > wrote:
>> I worked through the list of issues with the "numeric-tries-to-points” label 
>> and marked those as 7.0 Blocker that seemed reasonable, on the assumption 
>> that we should at a minimum give clear error messages for points 
>> non-compatibility.
>> 
>> If others don’t agree with the Blocker assessments I’ve made, I’m willing to 
>> discuss on the issues.
>> 
>> I plan on starting to work on the remaining 7.0 blockers now.  I would 
>> welcome assistance in clearing them up.
>> 
>> Here’s a JIRA query to see just the remaining 7.0 blockers, of which there 
>> are currently 12:
>> 
>> >  
>> >
>> 
>> --
>> Steve
>> www.lucidworks.com 
>> 
>> > On Jul 25, 2017, at 2:41 PM, Anshum Gupta > > > wrote:
>> >
>> > I will *try* to get to it, but can't confirm. If someone else has a spare 
>> > cycle and can take it up before I get to it, please do.
>> >
>> > -Anshum
>> >
>> > On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett > > > wrote:
>> > I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
>> > fields as deprecated) is SOLR-11023, which Hoss was working on. As he
>> > noted last night, he is off for vacation for the next 2 weeks. Is
>> > anyone else available to work on it so 7.0 isn't stalled for 2+ more
>> > weeks?
>> >
>> > Now would also be a good time to look over any other bugs with
>> > PointFields and make a case if any should be considered blockers for
>> > 7.0. I think they all share a label:
>> > https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points
>> >  
>> > 
>> >
>> > On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
>> > mailto:hossman_luc...@fucit.org>> wrote:
>> > >
>> > > : So, my overall point is that if A) we agree that we want to deprecate
>> > > : Trie* numeric fields, and B) we want to hold up the 7.0 release until
>> > > : that's done, it's more than just updating the example schemas if we
>> > > : want to ensure a quality app for users. We still need to fix the tests
>> > > : and also fix bugs that are going to be really painful for users. And
>> > > : to get all that done soon, we definitely need some more volunteers.
>> > >
>> > > I've beefed up the description of SOLR-10807 with tips on how people can
>> > > help out...
>> > >
>> > > https://issues.apache.org/jira/browse/SOLR-10807 
>> > > 
>> > >
>> > >
>> > >
>> > > -Hoss
>> > > http://www.lucidworks.com/ 
>> > >
>> > > -
>> > > 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 
>> > 
>> >
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For 

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 1945 - Unstable

[Tomas Fernandez Lobbe]

Related to SOLR-11015. I missed the case of the ChaosMonkeyNothingIsSafe*, that 
creates a different client with an explicit timeout for creating this 
collection. 

> On Jul 5, 2017, at 1:22 PM, Apache Jenkins Server  
> wrote:
> 
> Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1945/
> 
> 3 tests failed.
> FAILED:  
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test
> 
> Error Message:
> Timeout occured while waiting response from server at: 
> http://127.0.0.1:35634/d/d
> 
> Stack Trace:
> org.apache.solr.client.solrj.SolrServerException: Timeout occured while 
> waiting response from server at: http://127.0.0.1:35634/d/d
>   at 
> __randomizedtesting.SeedInfo.seed([FFF3B976A4923FDD:77A786AC0A6E5225]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1667)
>   at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1694)
>   at 
> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:297)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> com.carrotsearch.randomizedtes

Re: Better error message? (old version and new version are not comparable)

[Tomas Fernandez Lobbe]

Hi SG, 
You should create a Jira issue, then if you can rename your PR to include the 
Jira issue code in the title (that’s the way to link the Jira issue to the 
Github PR). Also, take a look at https://wiki.apache.org/solr/HowToContribute.

Tomás

> On Jun 12, 2017, at 9:14 AM, S G  wrote:
> 
> Hi Zheng,
> 
> We are using 6.3 version.
> I have created a small PR that addresses this issue of better error message.
> Please merge the same if it looks ok.
> https://github.com/apache/lucene-solr/pull/212/files 
> 
> 
> Thanks
> SG
> 
> 
> On Sun, Jun 11, 2017 at 8:45 PM, Zheng Lin Edwin Yeo  > wrote:
> Which version of Solr are yo using?
> 
> Also, I believe you should send this message to the user list at 
> solr-u...@lucene.apache.org 
> 
> Regards,
> Edwin
> 
> On 12 June 2017 at 02:45, S G  > wrote:
> Hi,
> 
> Recently I ran into an issue where the logs were showing the following:
> 
> 
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://solr-host:8983/solr/loadtest_shard1_replica1 
> : old version and new 
> version are not comparable: class java.lang.Long vs class java.lang.Integer: 
> null
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:765)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1173)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1062)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1004)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149) 
> ~[load-client.jar]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106) 
> ~[load-client.jar]
> at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:123) 
> ~[load-client.jar]
> at WriteLoadTest$IndexWorker.addDocsToSolr(WriteLoadTest.java:629) 
> [load-client.jar]
> at WriteLoadTest$IndexWorker.run(WriteLoadTest.java:573) 
> [load-client.jar]
> Caused by: 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://solr-host:8983/solr/loadtest_shard1_replica1 
> : old version and new 
> version are not comparable: class java.lang.Long vs class java.lang.Integer: 
> null
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:593)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:742)
>  ~[load-client.jar]
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient$$Lambda$8/745780984.call(Unknown
>  Source) ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> ~[?:1.8.0_51]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
>  ~[load-client.jar]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$7/725894523.run(Unknown
>  Source) ~[?:?]
> ... 3 more
> 
> 
> The message above is not clear at all.
> Which document is it talking about?
> I have so many documents being ingested and it's hard to figure out the same.
> It would have been nice if the message included a document ID too.
> 
> 
> Thanks
> SG
> 
> 
> 
> 
> 

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+171) - Build # 19780 - Failure!

[Tomas Fernandez Lobbe]

I noticed that with the JDK-9 builds, the MDC context doesn’t seem to work, 
anyone knows anything about this? Not sure if this is some issue with our 
build, with log4j or some configuration.

> On Jun 4, 2017, at 6:35 PM, Policeman Jenkins Server  
> wrote:
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19780/
> Java: 64bit/jdk-9-ea+171 -XX:+UseCompressedOops -XX:+UseG1GC
> 
> 1 tests failed.
> FAILED:  org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test
> 
> Error Message:
> Timed out waiting for replica core_node3 (1496625455425) to replicate from 
> leader core_node5 (1496625471655)
> 
> Stack Trace:
> java.lang.AssertionError: Timed out waiting for replica core_node3 
> (1496625455425) to replicate from leader core_node5 (1496625471655)
>   at 
> __randomizedtesting.SeedInfo.seed([9F609758DCEE1D0C:1734A882721270F4]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2117)
>   at 
> org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:207)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:563)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>   at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>   at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequir

Re: Replica naming changed.

[Tomas Fernandez Lobbe]

Thanks for the summary Erick. I’m also in favor of leaving the type as part of 
the name. In the future if we provide the option of changing the type of a 
replica I can see three options:
1) We do nothing with the name. The user who does replica type changes will 
have to know that this character is meaningless for them. Not the best option, 
specially if we provide an automated way to change the type.
2) We change the name of the replica to reflect the new type. May not be too 
easy, not sure how other parts of Solr will react to this, but may be the best 
approach.
3) We provide a way for users to define their own naming scheme for replicas 
(I’m thinking something like log4j logging pattern). Not sure if this will be 
needed really, it depends on how internal we consider the replica naming to be. 

Tomás

> On May 30, 2017, at 10:32 AM, Erick Erickson  wrote:
> 
> Tomás:
> 
> Thought that might be the case. I'm not opposed to the naming change
> as long as it serves a purpose as this one does. People shouldn't
> write scripts that assume hard-coded names anyway ;).
> 
> Ishan:
> 
> I give long odds that we _will_ need the capability to reassign
> replica roles. One of the points of this work is that people need to
> fine-tune how nodes on the cluster are utilized, which I'd imagine
> means reassigning replica functions.
> 
> All:
> 
> I rather like that the node name gives us information about the role.
> having to go to the state.json file to find some other property is
> onerous, especially in very large installations.
> 
> Proposal:
> 
> Let's keep the naming convention with the n, t, and p notation. If in
> the future we want to reassign a replica's role we can rename the node
> when its role changes.
> 
> On Tue, May 30, 2017 at 10:12 AM, Ishan Chattopadhyaya
>  wrote:
>> Do we shut ourselves out of the possibility to ever re-assigning the replica
>> types, by using this naming convention?
>> For example, is there any conceivable scenario in future whereby an NRT
>> replica can become a TLOG replica?
>> Never mind my asking if this flexibility is something we're sure we'll never
>> need.
>> 
>> On Tue, May 30, 2017 at 9:49 PM, Tomas Fernandez Lobbe 
>> wrote:
>>> 
>>> Hi Erick,
>>> This change is part of replica types. I mentioned this in SOLR-10233, but
>>> you are right, I should have mentioned probably in the dev list to get to
>>> more people. The last character represents the type of replica (n->NRT,
>>> t->TLOG, p->PULL). This is certainly not required and can be reverted back
>>> if people has concerns. I found it very useful when developing and I think
>>> it will also be helpful in prod, since the replica name is present in most
>>> log entries (since the MDC logging changes).
>>> 
>>> Tomás
>>> 
>>>> On May 30, 2017, at 8:54 AM, Erick Erickson 
>>>> wrote:
>>>> 
>>>> I noticed recently that our replica names are changing (master only?)
>>>> to collection_shard1_replica_n1. Why?
>>>> 
>>>> Mostly I wan to be sure we consider whether this change is worth the
>>>> confusion before it gets out into the wild. If it's just an aesthetic
>>>> change I question whether it's worth the confusion it'll generate. If
>>>> it serves a real purpose, that's another story..
>>>> 
>>>> Erick
>>>> 
>>>> -
>>>> 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
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC5

[Tomas Fernandez Lobbe]

+1

SUCCESS! [0:41:27.779418]

> On May 30, 2017, at 11:07 AM, Ishan Chattopadhyaya  wrote:
> 
> Please vote for release candidate 5 for Lucene/Solr 6.6.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC5-rev5c7a7b65d2aa7ce5ec96458315c661a18b320241
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC5-rev5c7a7b65d2aa7ce5ec96458315c661a18b320241
>  
> 
> 
> Here's my +1
> SUCCESS! [1:23:31.105482]

Re: Replica naming changed.

[Tomas Fernandez Lobbe]

Hi Erick, 
This change is part of replica types. I mentioned this in SOLR-10233, but you 
are right, I should have mentioned probably in the dev list to get to more 
people. The last character represents the type of replica (n->NRT, t->TLOG, 
p->PULL). This is certainly not required and can be reverted back if people has 
concerns. I found it very useful when developing and I think it will also be 
helpful in prod, since the replica name is present in most log entries (since 
the MDC logging changes). 

Tomás

> On May 30, 2017, at 8:54 AM, Erick Erickson  wrote:
> 
> I noticed recently that our replica names are changing (master only?)
> to collection_shard1_replica_n1. Why?
> 
> Mostly I wan to be sure we consider whether this change is worth the
> confusion before it gets out into the wild. If it's just an aesthetic
> change I question whether it's worth the confusion it'll generate. If
> it serves a real purpose, that's another story..
> 
> Erick
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC3

[Tomas Fernandez Lobbe]

I didn’t try this myself yet (just got a Windows machine to try it), but 
looking at Uwe’s comment here[1], I think this should be a blocker, half 
Windows users won’t be able to run the example. 


[1] 
https://issues.apache.org/jira/browse/SOLR-10735?focusedCommentId=16026393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16026393

> On May 26, 2017, at 8:34 AM, Ishan Chattopadhyaya  
> wrote:
> 
> Uwe, do you think this is a blocker?
> 
> On Fri, May 26, 2017 at 8:43 PM, Uwe Schindler  > wrote:
> Hi,
> 
>  
> 
> on my computer, the Solr one still does not start -see the whitespace in 
> directory name (my user name):
> 
>  
> 
> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin>solr.cmd start -e techproducts
> 
> Creating Solr home directory C:\Users\Uwe 
> Schindler\Desktop\solr-6.6.0\example\techproducts\solr
> 
>  
> 
> Starting up Solr on port 8983 using command:
> 
> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s 
> "C:\Users\Uwe Schindler\Desktop\solr-6.6.0\example\techproducts\solr"
> 
>  
> 
>  
> 
> ERROR: Failed to start Solr using command: C:\Users\Uwe 
> Schindler\Desktop\solr-6.6.0\bin\solr.cmd start -p 8983 -s "C:\Users\Uwe 
> Schindler\Desktop\solr-6.6.0\example\techproducts\solr" Exception : 
> org.apache.commons.exec.ExecuteException: Execution failed (Exit value: 
> -559038737. Caused by java.io.IOException: Cannot run program "C:\Users\Uwe" 
> (in directory "."): CreateProcess error=193, %1 ist keine zulässige 
> Win32-Anwendung)
> 
>  
> 
>  
> 
> C:\Users\Uwe Schindler\Desktop\solr-6.6.0\bin>
> 
>  
> 
> I will post this to the issue. Starting Solr without example works, but you 
> then have no core to quickly do tests.
> 
>  
> 
> FYI, I added a Linux and Windows build of branch_6_6 to Policeman Jenkins a 
> minute ago.
> 
>  
> 
> Uwe
> 
>  
> 
> -
> 
> Uwe Schindler
> 
> Achterdiek 19, D-28357 Bremen
> 
> http://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> 
> From: Ishan Chattopadhyaya [mailto:ichattopadhy...@gmail.com 
> ] 
> Sent: Friday, May 26, 2017 9:43 AM
> To: dev@lucene.apache.org 
> Subject: [VOTE] Release Lucene/Solr 6.6.0 RC3
> 
>  
> 
> Please vote for release candidate 3 for Lucene/Solr 6.6.0
>  
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3-revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781
>  
> 
>  
> You can run the smoke tester directly with this command:
>  
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC3-revbfb1ee42b2edbc2f2dea49b9d0e3201069d6e781
>  
> 
>  
> Here's my +1
> SUCCESS! [1:16:00.055493]
> 

Re: [JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.8.0_11) - Build # 4145 - Failure!

[Tomas Fernandez Lobbe]

I'm looking at this too, but I don't understand what the problem is yet.
May also be a problem with the javadocs of the classes I added.


2014-08-08 9:46 GMT-07:00 Chris Hostetter :

>
> Can someone who understands the python code in checkJavaDocs.py explain
> what this error means?
>
> I know tommaso added/fixed a javadoc include problem with LUCENE-5878, but
> that seemed to be causing a differend (intelligable) javadoc-lint error in
> other builds ... i'm not understanding what the real problem is from this
> error
>
>
>
> : Date: Fri, 8 Aug 2014 16:18:44 + (UTC)
> : From: Policeman Jenkins Server 
> : Reply-To: dev@lucene.apache.org
> : To: tomm...@apache.org, tflo...@apache.org, markrmil...@apache.org,
> : hoss...@apache.org, dev@lucene.apache.org
> : Subject: [JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.8.0_11) - Build #
> 4145
> : - Failure!
> :
> : Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4145/
> : Java: 64bit/jdk1.8.0_11 -XX:-UseCompressedOops -XX:+UseG1GC
> :
> : All tests passed
> :
> : Build Log:
> : [...truncated 45039 lines...]
> : -documentation-lint:
> :  [echo] checking for broken html...
> : [jtidy] Checking for broken html (such as invalid tags)...
> :[delete] Deleting directory
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\jtidy_tmp
> :  [echo] Checking for broken links...
> :  [exec]
> :  [exec] Crawl/parse...
> :  [exec]
> :  [exec] Verify...
> :  [echo] Checking for missing docs...
> :  [exec] Traceback (most recent call last):
> :  [exec]   File
> "C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\dev-tools/scripts/checkJavaDocs.py",
> line 371, in 
> :  [exec] if checkPackageSummaries(sys.argv[1], level):
> :  [exec]   File
> "C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\dev-tools/scripts/checkJavaDocs.py",
> line 351, in checkPackageSummaries
> :  [exec] if checkClassSummaries(fullPath):
> :  [exec]   File
> "C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\dev-tools/scripts/checkJavaDocs.py",
> line 215, in checkClassSummaries
> :  [exec] missing.append((lastCaption, unEscapeURL(lastItem)))
> :  [exec]   File
> "C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\dev-tools/scripts/checkJavaDocs.py",
> line 303, in unEscapeURL
> :  [exec] s = s.replace('%20', ' ')
> :  [exec] AttributeError: 'NoneType' object has no attribute 'replace'
> :
> : BUILD FAILED
> : C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:474:
> The following error occurred while executing this line:
> : C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:63:
> The following error occurred while executing this line:
> :
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:212:
> The following error occurred while executing this line:
> :
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:242:
> The following error occurred while executing this line:
> :
> C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:2347:
> exec returned: 1
> :
> : Total time: 183 minutes 16 seconds
> : Build step 'Invoke Ant' marked build as failure
> : [description-setter] Description set: Java: 64bit/jdk1.8.0_11
> -XX:-UseCompressedOops -XX:+UseG1GC
> : Archiving artifacts
> : Recording test results
> : Email was triggered for: Failure - Any
> : Sending email for trigger: Failure - Any
> :
> :
> :
>
> -Hoss
>