lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3846) TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
Date Mon, 17 Sep 2012 05:36:07 GMT

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

Mark Miller commented on SOLR-3846:
-----------------------------------

I suppose the most suspicious looking fellow is:
{code}
"qtp1716711701-794" prio=5 tid=7fe8a1b03800 nid=0x10f124000 waiting for monitor entry [10f122000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at java.security.Permissions.implies(Permissions.java:162)
	- waiting to lock <7dee37460> (a java.security.Permissions)
	at sun.security.provider.PolicyFile.implies(PolicyFile.java:1111)
	at java.security.ProtectionDomain.implies(ProtectionDomain.java:224)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:352)
	at java.security.AccessController.checkPermission(AccessController.java:546)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
	at java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:107)
	at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.ConstructorConstructor.newDefaultConstructor(ConstructorConstructor.java:84)
	at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.ConstructorConstructor.getConstructor(ConstructorConstructor.java:66)
	at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:64)
	at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.internal.bind.MiniGson.getAdapter(MiniGson.java:92)
	at com.carrotsearch.ant.tasks.junit4.dependencies.com.google.gson.Gson.toJson(Gson.java:504)
	at com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:61)
	- locked <7dee9ec18> (a java.lang.Object)
	at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$4.write(SlaveMain.java:329)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
	- locked <7dee420a0> (a java.io.BufferedOutputStream)
	at java.io.PrintStream.flush(PrintStream.java:288)
	- locked <7deeaebc8> (a java.io.PrintStream)
	at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:278)
	at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
	- locked <7def6b868> (a java.io.OutputStreamWriter)
	at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
	at java.util.logging.StreamHandler.flush(StreamHandler.java:225)
	- locked <7def6ae48> (a java.util.logging.ConsoleHandler)
	at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:89)
	at java.util.logging.Logger.log(Logger.java:478)
	at org.slf4j.impl.JDK14LoggerAdapter.log(JDK14LoggerAdapter.java:579)
	at org.slf4j.impl.JDK14LoggerAdapter.info(JDK14LoggerAdapter.java:276)
	at org.apache.solr.update.processor.LogUpdateProcessor.finish(LogUpdateProcessorFactory.java:210)
	at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:83)

{code}
                
> 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: 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message