It is, of course, a balancing act. On the one hand, if you disable/remove tests that are pesky, somehow they often get permanently ignored. We all have other pressing priorities.
If you leave them in, people trying to do stuff, really haven't a clue why they can't run tests, and are more likely to throw up their hands. What I'd like is a way, OOB, for someone to follow the instructions on the "how to contribute" Solr page and not be surprised. This case was peculiar, seems to be a problem with BSD (?), see Uwe's patch (which I'm testing right now, seems to work with a modification). So I'm not sure what would have been the right thing to do. We already have the "nightly" annotation. Does it work to move often-failing tests run then? Or to some other annotation that's off by default? Or even on by default but put a big warning and/or suggestion on the "How To Contribute" page, something like "feel free to check in code if test pass when you turn off 'RunPeskyTests' "? The goal here is to have no excuse for _not_ running the tests, but minimal pain _to_ run them. FWIW, Erick On Mon, Sep 17, 2012 at 2:57 AM, Dawid Weiss (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456842#comment-13456842 > ] > > Dawid Weiss commented on SOLR-3846: > ----------------------------------- > > bq. And I'm soooo happy it's not happening to others and just being swept > under the rug, restores my faith. I should have known better > > Yes, I'm for sweeping things that don't work under the (JIRA-marked and > annotated) rug, Yonik. Otherwise you get people like Erick who are on the > edge of not running tests at all. I think it's bad and I think this kind of > shows we're both right but have a different angle on this. > >> TestReplicationHandler.test always (?) takes many minutes on OS X (lion) >> ------------------------------------------------------------------------ >> >> Key: SOLR-3846 >> URL: https://issues.apache.org/jira/browse/SOLR-3846 >> Project: Solr >> Issue Type: Improvement >> Components: Build >> Affects Versions: 4.0-BETA, 5.0 >> Environment: OS X (Lion). Apparently (see Yonik's notes) this does >> NOT happen on other op systems. >> java version "1.6.0_35" >> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811) >> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode) >> Solr trunk and 4.x from 16-Sep, but it's been happening for a couple of >> weeks at least. >> Reporter: Erick Erickson >> Fix For: 4.0, 5.0 >> >> Attachments: SOLR-3846.patch, stacks.txt >> >> >> Here's the seed was using, but this is apparently unnecessary: >> <JUnit4> says ¡Hola! Master seed: 6785BB3284A15298 >> _eventually_ it seems to complete, but it takes many minutes, for instance >> this was reported once, but I usually lose patience and ctrl-c out: >> {code} >> [junit4:junit4] Completed on J2 in 2449.62s, 1 test >> [junit4:junit4] >> [junit4:junit4] JVM J0: 1.21 .. 266.67 = 265.47s >> [junit4:junit4] JVM J1: 1.21 .. 238.33 = 237.12s >> [junit4:junit4] JVM J2: 1.21 .. 2538.60 = 2537.39s >> [junit4:junit4] JVM J3: 0.97 .. 267.37 = 266.40s >> [junit4:junit4] Execution time total: 42 minutes 18 seconds >> {code} >> and a lot of lines like: >> HEARTBEAT J2: 2012-09-16T17:38:38, no events in: 187s, approx. at: >> TestReplicationHandler.test >> Yonik reports that he can make this happen 100% of the time on OS X/Lion, >> which squares with my experience as I recall. Yonik also reports... >> On my linux box (built in '09, PhenomII, HDD) the test takes 50-55 sec. >> On my kids old windows box ('08, athlon64, HDD, Win7) the test takes 88-95 >> sec. >> On my mac it always takes forever, and I see loops of stuff like this: >> {code} >> SEVERE Master at: http://localhost:62803/solr is not available. Index >> fetch failed. Exception: >> org.apache.solr.client.solrj.SolrServerException: Server refused >> connection at: http://localhost:62803/solr >> [junit4:junit4] 2> 52751 T219 C17 UPDATE [collection1] webapp=/solr >> path=/update params={wt=javabin&version=2} {add=[150]} 0 0 >> [junit4:junit4] 2> 52755 T219 C17 UPDATE [collection1] webapp=/solr >> path=/update params={wt=javabin&version=2} {add=[151]} 0 0 >> [junit4:junit4] 2> 62758 T215 oash.SnapPuller.fetchLatestIndex >> SEVERE Master at: http://localhost:62803/solr is not available. Index >> fetch failed. Exception: >> {code} >> And I'm soooo happy it's not happening to others and just being swept under >> the rug, restores my faith. I should have known better ;) >> See the discussion on the dev list labeled "being a good citizen is hard >> when you can't successfully run tests" for more context. >> I don't know how much time I'll have to dive in to it but I'll certainly be >> happy to test anyone's patch. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
