: Unfortunately this is not so easy. It is always the same Jenkins Job,
: the randomization is part of the dynamic JAVA_HOME. So the mail is
Ah ... ok. What about adding a second (no mail configured) job for
"untrusted" JDK9 (and if we start getting them: new IBM J9) builds?
ie: your existin
: It was just a try with newer build. And no, the machine has no hardware
: failure, happens all the time with JDK 9 L - and only with Java 9 b67+
Uwe: perhaps you could change your JDK9 jenkins job to run but not send
emails on failures?
then at least we can still generate reports, and test n
: In the scenario outlined below, the second run's timeAllowed parameter
: is unexpectedly ignored. Could this be intentionally so somehow (q vs.
: fq processing?, Collector vs. LeafCollector?, DocList vs. DocSet?), or
: is it an edge-case bug?
Based on your description (didn't re-review the c
class is completely untested with "strange" date
: > formats.
: > Uwe
: >
: > -
: > Uwe Schindler
: > H.-H.-Meier-Allee 63, D-28213 Bremen
: > http://www.thetaphi.de
: > eMail: u...@thetaphi.de
: >
: >
: > > -Original Message-
: >
with pervious b70 was
: > > failed horrible and did not even reach Solr (arraycopy bugs), so the bug
may
: > > have introduced in b61 or later.
: > >
: > > Uwe
: > > -
: > > Uwe Schindler
: > > H.-H.-Meier-Allee 63, D-28213 Bremen
: > > htt
2 nearly identical failures from policeman immediatley after upgrading
jdk1.9.0 to b71 ... seems like more then a coincidence.
ant test -Dtestcase=ExtractingRequestHandlerTest -Dtests.method=testArabicPDF
-Dtests.seed=232D0A5404C2ADED -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=en_
FWIW: Steve looked in to this a bit ago and filed SOLR-7611...
https://issues.apache.org/jira/browse/SOLR-7611
...my impression at the time was that LUCENE-6505 totally invalidated the
entire premise of the test, but i didn't spend that much time looking into
it. But then stem said he was abl
Ummm, david ... i hate to tell you this, but it looks like you forgot the
"L" in "Solr" in the title of your own book.
more then once.
:)
: Mitchell](https://www.linkedin.com/in/mattmitchell4) are proud to
: *finally* announce the book â??[Apache Sor Enterprise Search Server,
...
:
seeds don't reproduce 100% reliably at the moment, but beasting them
triggers pretty quick.
this seems to corolate to a change made in this test yesterday for
SOLR-7622 -- i've posted comments there with details ... hopefully ryan /
noble can take a look ASAP and figure out what went wrong.
: For the record, there is an experimental postings format in
: lucene/sandbox called IDVersionPostingsFormat that stores both the ID
: and version in a postings format. This way you don't have to perform
: additional seeks to look up the version, and it's even optimized for
: id look ups with a m
: I don’t know if it’s worth it in terms of the trade-offs, but there’s
: something to be said about having *both* indexed=true & docValues=true on
Yes that's true -- and: again ... not at all what Ishan is asking
about.
(The tradeoffs between DV and indexed are known and the question of how
t
This thread kind of got off into a tangent about solr specifics -- if you
skip down it's really a question about underlying performance concerns of
using docvalues vs using stored fields.
: 1. _version_ never needs to be searchable, thus, indexed=false makes
sense.
Unless i'm wrong, the
Opened: https://issues.apache.org/jira/browse/SOLR-7706
...tracked to being caused by LUCENE-6583.
: Date: Fri, 19 Jun 2015 10:13:30 -0700 (MST)
: From: Chris Hostetter
: To: dev@lucene.apache.org
: Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) -
: Build
There have been 6 failures of this test (on trunk) with the same root
cause (but diff docids) in the last 24 hours...
: 1 tests failed.
: FAILED: org.apache.solr.search.join.BJQParserTest.testChildrenParser
:
: Error Message:
: Exception during query
:
: Stack Trace:
: java.lang.RuntimeExcept
: Clearly they're coming from Elastic..
pretty sure it's just standard moderatation queue stuff...
the first time a (non-subscribed) addr sends an email to the list, it gets
held in the queue -- if the moderator just hits "reply" tothe "accept"
address, then that one message will make it t
: Please VOTE to release these files as the Solr Ref Guide 5.2...
:
:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.2-RC0/
The VOTE has passed, i'll start pushing to the mirrors.
-Hoss
http://www.lucidworks.com/
--
: Please VOTE to release these files as the Solr Ref Guide 5.2...
:
:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.2-RC0/
My vote...
+1 to releasing this artifact...
$ sha1sum apache-solr-ref-guide-5.2.pdf
e1d7d658a0233dc4a46bc6e4951051d4c3935541 apach
Please VOTE to release these files as the Solr Ref Guide 5.2...
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.2-RC0/
NOTE: this vote will be open for a minimum of 72 hours, but i will not
call this (ref guide) vote to a close until the 5.2.0 code release
;
: > If anyone at bbuzz sees Uwe please ask him to check his mail and spend 5
: > minutes updating this cwiki setting :)
: >
: >
: > : Date: Mon, 1 Jun 2015 10:52:45 -0700 (MST)
: > : From: Chris Hostetter
: > : To: Uwe Schindler
: > : Cc: Lucene Dev
Uwe: this is blocking our ability to release the ref guide.
If anyone at bbuzz sees Uwe please ask him to check his mail and
spend 5 minutes updating this cwiki setting :)
: Date: Mon, 1 Jun 2015 10:52:45 -0700 (MST)
: From: Chris Hostetter
: To: Uwe Schindler
: Cc: Lucene Dev
: Subject
FYI: this is currently on hold while we wait for the javadoc shortcut
links to be updated (i always forget to plan ahead for timing that step)
: Date: Wed, 27 May 2015 09:57:46 -0700 (MST)
: From: Chris Hostetter
: To: Lucene Dev
: Subject: Solr Ref Guide 5.2 RC Planning - aiming for RC0 on
Uwe, can you please go ahead and update the CWIKI javadoc macro links to
point to the 5_2_0 paths (they don't exist yet, but i'd like to get the
ball rolling so we can try to get the ref guide out not long after the
release)
https://cwiki.apache.org/confluence/display/solr/Internal+-+How+Jav
+1
: Date: Sun, 31 May 2015 04:30:00 + (UTC)
: From: "David Smiley (Confluence)"
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [CONF] Apache Solr Reference Guide > Other Parsers
:
: [IMAGE]
: David Smiley edited the page:
:
: [IMAGE] OTHER PARSERS
:
: Comme
Joel: that table is pretty dense -- i would suggest instead using an
subsection for each "Stream Function" with a table for the params (name,
description, required/optional, sample input) and a code block for a
cohesive example of that function.
I would also suggest changing the URL in the "H
I've updated SOLR-7603 with the new details from the
UpdateRequestProcessorFactoryTest failure and will try to make sense of
that.
Anybody have any clue what's up with the HttpPartitionTest test here?
leaking file handles on the segments file?
: Date: Fri, 29 May 2015 09:42:29 + (UTC)
:
I'm volunteering to be the RM for the 5.2 ref guide.
Now that anshum has started on the 5.2 (code) RC process, we need to
knuckle down on the ref guide as well. I'm about to start reviewing &
summarizing the CHANGES.txt list for notable things that need doc'ed which
i'll post on the TODO pag
: The default timeout seems to be 720 millis, this means 7200
: seconds or ~120 minutes. Look for @TimeoutSuite annotation in the
thanks ... my bad -- i did look for TimeoutSuite in the test, but i
thought the default was 60 minutes. (forgot to double check that
assumption)
false alarm (on
: Right, as I said, we weren't hitting this issue due to our Kerberos conf.
: file. i.e. the only thing that was different on our machines as compared to
: everyone else and moving that conf file got the tests to fail for me. It
: now fails fairly consistently without the patch (from SOLR-7468) an
Dawid: seperte from the questions raised in Jira about hte underlying
problem in Solr, any ideas why the framework didn't time this test out
long before the 110 minute mark when i noticed it still running?
(I don't see anything in the test or it's baseclass overriding hte default
timeouts.)
: I am fairly new to Solr development, so apologies for an obvious
: question. Do you cut 5.x releases from trunk or some other branch/tag?
: The reason I am asking is that trunk currently builds as 6.0.0 snapshots
: and there are a bunch of Lucene and Solr API differences between 5.1 and
: tr
>> Please understand that by taking this attitude you waste everyone
>> else's time who does want to pass "ant precommit" before committing,
>> and everyone else's time to scan all these broken builds emails.
+1
personally ... i'm past the point of willing to overlook people who
obviously break
: What's the deal with this?
:
: BROKEN LINK:
file:///home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/docs/solr-core/org/apache/solr/search/facet/FacetMerger.Context.html
:
: FacetMerger.Context has no javadoc!
heh ... "Context" is everything.
the *full* error is telling you that whil
This violates "ant precommit" because of forbidden API (default charset)
problems.
: Date: Thu, 07 May 2015 13:33:23 -
: From: no...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: svn commit: r1678195 - in /lucene/dev/trunk/solr: ./
: contrib/da
: Yes, the new UI is available via http://localhost:8983/solr/index.html.
...
: As to how URLs are managed, the web.xml welcome-file currently causes
: http://localhost:8983/solr/ to point to admin.html. The new UI is
: accessible via http://localhost:8983/solr/index.html. Switch the
: wel
(cross posted, please confine any replies to general@lucene)
A quick reminder and/or heads up for htose who haven't heard yet: this
year's Lucene/Solr Revolution is happeing in Austin Texas in October. The
CFP and Early bird registration are currently open. (CFP ends May 8,
Early Bird ends
: Once that's done, switching should just be a question of changing the
: welcome-file in web.xml.
My suggestion, along the lines of what we did with the previous UI
change...
1) ensure that the new UI is fully functional in 5x using an alt path
(believe this is already true?)
2) add an "Upgr
: If we wanted to allow overriding that, would that go into solr.xml or
: web.xml? If it's solr.xml, can you point me to where this class gets
: parsed/handled?
there isn't really any overriding of this sort of thing supported right
now -- as far as i can remember no ones ever put any work/thoug
: I tried to set the default response writer for admin operations to JSON by
: putting the following in solrconfig.xml:
there's two types of admin requests -- "core" based and global
:
..that sets the default response writer for the core(s) using that config.
: curl -i -X GET http://localho
Hey Shai,
The CHANGES.txt additions you made here (and for SOLR-7325) are only in
the "Upgrading" section.
Specific CHANGE entries (with credit to contributors) should always exist
in one of the "Detailed Change List" sections (in this cases, probably
either "new features" or "other changes
: The PDF is available at:
:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.1-RC0/
+1 to releasing...
af80178bd864ffe0a354c8780c22296808d0423b apache-solr-ref-guide-5.1.pdf
-Hoss
http://www.lucidworks.com/
--
FYI: Uwe replied to me privately a few hours ago that he had done this.
: Date: Wed, 15 Apr 2015 09:14:11 -0700 (MST)
: From: Chris Hostetter
: To: u...@thetaphi.de
: Cc: Lucene Dev
: Subject: Updating CWIKI jdoc link macros -- was: Re: Solr Ref Guide for 5.1
:
:
: Uwe: can you please update
Noble - did you consider how this change affects the JSON section as a
whole?
You've now using the convinience path /update/json/docs in an example, 2
sub-sections before those convinience paths are introduced.
the strucutre was setup so that the basics of sending JSON were explained
first *t
Uwe: can you please update the confluence link macros for the lucene/solr
javadoc urls to reflect "5_1_0" ?
>> To update the shortcut links to point to the current version, remove
>> and recreate the shortcut links with keys SolrReleaseDocs and
>> LuceneReleaseDocs , making their expanded valu
: This fail seems like I might have missed something doing the 5.1
: release ... any thoughts?
I think it's a post release step? once the release is final, someone needs
to manually generate test indexes (using the released version of the code)
and then commit those on trunk & backport to the s
This NPE reproduces for me regardless of what seed is used.
Looks like a bug introduced by r1669368 for SOLR-7226 ?
New logic & asserts were added to TestSolrConfigHandler which is
subclassed by TestSolrConfigHandlerCloud and boom goes the dynamite.
: Date: Thu, 26 Mar 2015 22:22:50 + (U
looks like this broke precommit?
/home/hossman/lucene/5x_dev/extra-targets.xml:204: The following files are
missing svn:eol-style (or binary svn:mime-type):
*
./solr/solrj/src/test/org/apache/solr/client/solrj/CollectionAdminRequestRequiredParamsTest.java
: Date: Thu, 26 Mar 2015 20:24:35 -0
SOLR-7215
: Date: Fri, 20 Mar 2015 16:17:45 -0400
: From: Yonik Seeley
: Reply-To: dev@lucene.apache.org
: To: Solr/Lucene Dev
: Subject: failure from excessive output
:
: Just got a failure from a test that doesn't have any output at all
:
:
:
: java.lang.AssertionError: The
: I don't really understand SPI and class loaders, but you are right this
: class is a subclass of PostingsFormat not Codecs. So is there an issue
: with the whole idea, or is there just some subtlety of class loading and
: the SPILoader I'm not understanding?
SPI is just a mechanism Java gives
Hmm.. i spotted this when doing the backport to 5x, but i thought i fixed
it -- digging in more now.
: 6 tests failed.
: REGRESSION: org.apache.solr.TestDistributedSearch.test
:
: Error Message:
: .stats.stats_fields[severity].facets.severity.Low!=High (unordered or missing)
: Date: Tue,
: The change had no functional impact, hence left it alone.
:
: But happy to follow whatever is the existing practice. Should I have one
: for every change?
anything non trivial should be noted in CHANGES.txt - the "Other
Changes" section is good fit for internal refacotrings that don't fix any
: I've been experimenting with the new start script in 5.0, and have come
: across something I can't figure out. It's easy enough to start up a
: SolrCloud example ("bin/solr start -e cloud", answer the prompts) ...
: but once I've done that, how do I restart it without telling it how to
: build
: Hmm, this is indeed not documented. I'll fix.
It's definitely documented...
https://cwiki.apache.org/confluence/display/solr/Transforming+Result+Documents
https://cwiki.apache.org/confluence/display/solr/Function+Queries#FunctionQueries-UsingFunctionQuery
https://cwiki.apache.org/confluence/di
: it's OK that 4.10.x back compat test fails to test 5.x indices :)
FWIW: using something like python's distutils.version.StrictVersion to
compare the current RC version with each of hte items in allReleases might
help make this less tedious down the road...
(is distutils a standard python lib
I re-opened LUCENE-6277 ...
https://issues.apache.org/jira/browse/LUCENE-6277
: Date: Mon, 23 Feb 2015 23:01:25 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: sar...@gmail.com, dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.
Vote has passed, i've started the process of pushing to the mirrors.
: Date: Mon, 16 Feb 2015 11:32:26 -0700 (MST)
: From: Chris Hostetter
: To: Lucene Dev
: Subject: VOTE: RC1 Release apache-solr-ref-guide-5.0.pdf
:
:
: Please vote to release the following artifacts as the Solr 5.
I think anshum already fixed tihs this?
was caused by commits in SOLR-6956.
: Date: Wed, 18 Feb 2015 00:43:26 + (UTC)
: From: Policeman Jenkins Server
: Reply-To: dev@lucene.apache.org
: To: sha...@apache.org, jpou...@apache.org, rm...@apache.org,
: dev@lucene.apache.org
: Subject: [J
: The artifacts can be downloaded here:
: http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC3-rev1659987
+1 to releasing the following artifacts...
hossman@frisbee:~/tmp/lucene-solr-5.0.0-RC3-rev1659987$ cat */*.sha1
1840fff82b0e6050cf42042dfe714a5bd9046c89 *lucene-5.0.0-src.tgz
2
: It would be good if this comment was fixed -
Perfection is the enemy of good ... there's always going to be things that
could be improved. hopefully someone who knows the code can review &
address that comment soon, but in the meantime it doesn't seem like it
should warrant blocking the rel
:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.0-RC1/
+1 to releasing the following artifact...
cat apache-solr-ref-guide-5.0.pdf.sha1
cb3991c50ce4e85c0fb97fe6c0baf457e50bea10 apache-solr-ref-guide-5.0.pdf
-Hoss
http://www.lucidworks.com/
---
Can not reproduce, and you did't give enough context to in the
exception to even know where in the code that exception is being
triggered.
That class is a package protected "sibling" class of SolrIndexSearcher (i
forget the technical name) so perhaps your problem is simply a compilation
glitc
Please vote to release the following artifacts as the Solr 5.0 Ref
Guide...
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.0-RC1/
-Hoss
http://www.lucidworks.com/
-
To unsubscribe, e-
: Yes, I think it might make sense to wait and respin around the same time as
: the next Lucene/Solr RC.
I should have clarified when i initially sent out hte RC...
All ASF Votes are open for a minimum of 72 Hours, but it is my intention
not to call this RC (or any future RC) 5.0 ref-guide vote
Jan: I'm not sure if it was this commit, or one of hte other HTML related
commits you did arround the same time, but something has broken the
dynamic way the search box use to appear on the solr pages (as well as
pushing down & mucking with the spacing arround the "Solr is the
popular..." sent
Please vote to release the following artifact as the "Apache Solr
Reference Guide for Solr 5.0" ...
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.0-RC0/
-Hoss
http://www.lucidworks.com/
-
FYI: still on track to do this tomorow (about 23HR after i send this
email)
: Date: Fri, 6 Feb 2015 15:09:41 -0700 (MST)
: From: Chris Hostetter
: To: Lucene Dev
: Subject: 5.0 Solr Ref Guide Release Plans (RC0 ~ Thurs 2015-02-12)
:
:
: I'm volunteering to be the RM for the 5.0 ref
: : That part of the script expects you run from the root of a checkout. It
: : runs the backcompat tests, and scrapes the test output to check all are
: : tested.
:
: Everything you said made sense, and i even filed LUCENE-6234 to note that
I tracked down the root problem to LUCENE-6235 - the
: That part of the script expects you run from the root of a checkout. It
: runs the backcompat tests, and scrapes the test output to check all are
: tested.
Everything you said made sense, and i even filed LUCENE-6234 to note that
we should improve the behavior -- and yet even when i run smoke
: Or you can run the smoke tester directly with this command:
: python3.2 dev-tools/scripts/smokeTestRelease.py
: http://people.apache.org/~anshum/staging_area/lucene-solr-5.0.0-RC2-rev1658469
smokeTestRelease.py is freaking out for me regarding back compat
testing -- i haven't had a chance to i
Miller: can you please clarify what exactly this means for users in terms
of what other methods of collection creation you have in mind that are
"unsupported, not recommended"
All you say here is "not using the collections API" -- but what does that
mean?
(Are you talking about things like
I'm volunteering to be the RM for the 5.0 ref guide, wanted to get my
plans on the radar for folks.
The ref guide is in pretty good shape as far as some of the really "meaty"
changes that are in 5.0 - there are still some new features that need
documented, but there always are in every relea
: Until 5.x Solr would start on whatever port of the appserver chosen, i.e.
8983 for Jetty, 8080 for Tomcat etc.
: Now that Solr is a "standalone" app, why should we "inherit" Jetty's default
port 8983 anymore?
last time i checked, 8983 is not "Jetty's default port" ... Jetty's
hardcoded defaul
It's our old friend SOLR-6387 !
This time manifesting itself via calls down into Tika.
My best guess is that something changed in the recently upgraded version
of Tika in Solr so that we now tickle this ExternalParser code path in a
way we never tickled it before ... but more perplexing is why
this looks like problems noted in SOLR-6915 wih the kerberose stuff and
the IBM JDK.
miller? gregory? ... were you guys going to disable these tests on IBM
JDKs or not?
It's one thing to say a certain feature only works with Oracle JVMs, but
it's going to suck if 5.0 goes out and we know tha
: It's our old friend SOLR-6387 !
:
: This time manifesting itself via calls down into Tika.
new comments posted in SOLR-6991 where Tika was upgraded -- definitely
Tika 1.7 that introduced this new parser that causes this problem.
One followup clarification...
: way we never tickled it before
: Solr's ant example is no more on trunk and branch_5x ... use ant server,
: see SOLR-6926
i know i'm the one that filed the issue, but i think it might be prudent
to add an undocumented crunch target for people suffering from muscle
memory - ala...
! ! ! NOTICE NOTICE NOTIC
: I am trying to check if there are any documents in Solr but they are
: not visible yet.
...
: But if there was a hard commit with openSearcher=false (as per example
: configuration), then that number resets to 0 on commit.
:
: Is there a different property somewhere showing what's not y
the maven build has had failed comilation on trunk since Jan-8 due to the
"Filter" class not being found when compiling JettySolrRunner...
[mvn]
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-trunk/solr/core/src/java/org/apache/solr/client$
[mvn] class file for javax.
As some folks may have noticed, i started a page a while back to try and
audit all of the "big" things that needed changed in the ref guide related
to the new "bin/solr" and example->server changes that will be coming in
5.0 (above and beyond the usual "new feature in changes, so let's add
it
since this page said straight up on the first line that it was a work in
progress, i reparented it to be under the "Internal - Trunk Changes to
Document" page since that's where new pages should live until they are
ready to be included in the doc.
: Date: Fri, 2 Jan 2015 13:49:00 + (UTC)
:
: Please provide the details of the errors you’re seeing, and any relevant
: environmental details - that would have been higher impact than not
: providing details :)
when in doubt: file a jira, attach all the details.
-Hoss
http://www.lucidworks.com/
---
Rory: Dawid has given a bunch of great talks on our randomized testing
setup over the years that are available online -- watch them all and you
can even see how the aggressiveness of what we randomize has evolved...
2011: http://vimeo.com/32087114
2013: https://www.youtube.com/watch?v=zD57QKzqd
(NOTE: cross posted to several lucene lists, if you have replies, please
confine them to general@lucene)
-- Forwarded message --
In case you've missed it:
- ApacheCon North America returns to Austin, Texas, 13-17 April 2015
http://apachecon.com/
- Call for Papers open until
anshum: there are probably enough people using post.jar in scripts that we
should call this out in the top "upgrading" section of CHANGES.txt for
5.0, with an example of how existing calls need to be modified.
: Date: Tue, 16 Dec 2014 07:25:17 -
: From: ans...@apache.org
: Reply-To: dev@luc
It helps if you create a Jira as well -- particularly if you then refer to
the jira ID in your pull request, because then that way it's autolinked in
jira -- because we strive to have a jira tracking any non-trivial change
so it's got an easy refrence point for tracking in CHANGES.txt, and for
: The current documentation 4.10 ref guide says it is " disabled by default"
: which apparently has not been true for several years. I just put a comment
: in the current ref guide to this effect.
updated, as you noted - the doc idd point out hte example config uses
enableRemoteStreaming="true"
: In revision 743163 of the Solr 4.10 example solrconfig.xml file
: enableRemoteStreaming was (accidentally?) changed from "false" to true.
yeah ... that was 5 years ago.
I dont remember specifically if it was an accident at the time, but the
inclusion in release versions since has been in
: Before looking too hard at the links (will later):
Maybe i wasn't explicitly clear enough about what i was trying to focus on
-- but then again, maybe if you'd looked at the links i had provided it
would have been implicitly clear enough :)
Both of your comments are accurate and good suggest
There have been a lot of structural changes to what a solr release will
look like starting with 5.0, and how we intend/expect people to run Solr
-- both to try the example(s) and in a "production installation"
With that in mind, i created a new meta-page in the ref guide to try and
track:
Uh ... miller? WTF?
: Date: Tue, 09 Dec 2014 17:11:30 -
: From: markrmil...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: svn commit: r1644122 - /lucene/lucene-solr-trunk-1/
:
: Author: markrmiller
: Date: Tue Dec 9 17:11:30 2014
: New Revision: 16
https://issues.apache.org/jira/browse/INFRA-8825
I don't know why svn is setup to forward emails to g...@git.apache.org -
even though i'm seeing bounce messages for commits, they still seem to be
showing up in the git mirror.
but be advised that you will likelye start seeing these ~5 days af
: unreleased Solr version showing in Jira -- SOLR-6607.
pretty sure this was a mistake -- the assocaited issue was SOLR-5641 and
looking at that issue, it appears noble was trying to "resolve as
duplicate of SOLR-6607" and just typed the issue # into the wrong box.
(because jira tries to be rea
I'll be on a plane in a few hours, but here's the 4.x patch to fix once
SVN starts working again...
Index:
lucene/test-framework/src/java/org/apache/lucene/search/BaseExplanationTestCase.java
===
---
lucene/test-framework/src/ja
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
: I'll fix the message to make it clear you are not running on WINDOWS
: but rather our WindowsFS.
thanks.
: I agree we should strive to have our tests be portable across OS's ...
:
: But unfortunately this test case is for a nasty corruption bug
: (LUCENE-5574) that can't happen on Windows...
: assumeFalse("this test can't run on Windows", Constants.WINDOWS);
:
: MockDirectoryWrapper dir = newMockDirectory();
: +if (TestUtil.isWindowsFS(dir)) {
: + dir.close();
: + assumeFalse("this test can't run on Windows", true);
: +}
this specific assume msg seems li
: Its easiest to explain i think by pasting the code. for 10% of runs we
: don't wrap the filesystem at all. This is to ensure our "mock
Ah - ok. the 10% use "real" filesystem is the biggest part i was missing.
So 90% of the time we wrap the filesystem in special checks; and 10% of
the time wh
: windowsfs uses map to determine if it can delete a
: file, but this is troublesome on windows. One problem is that we cant
: 100% compare files for equality without doing i/o. And doing this
: itself can piss "the real windows" off. So I just disable windowsfs on
: actual windows for now, i don'
Apologies -- I haven't been following the commits closely this week.
Does anyone have any idea what changed at the low levels of the Solr
testing class hierarchy to cause these failures in a variety of tests?
: SolrCore 'collection1' is not available due to init failure: Error
: instantiating
I can't reproduce this, and i don't really understand it, but i know
anshum was working on this very recently so i filed a jira for him so we
don't lose track of it...
https://issues.apache.org/jira/browse/SOLR-6755
: Date: Tue, 18 Nov 2014 04:01:34 + (UTC)
: From: Policeman Jenkins Server
Posting the specific details of the NPEs you are seeing (ie: stack
traces) would help to answer your question.
Some of the functionality in LTC is definitely tied to the JUnit test case
lifecycle, so it's certainly possible that some static objects used by
static methods aren't being initializ
301 - 400 of 1146 matches
Mail list logo
