I'll try to minimize a failing test-case. Our team suspects that this is somehow related to java 1.8.0_60 update, but we don't have strong proofs for that.
W dniu środa, 9 września 2015 11:10:00 UTC+2 użytkownik Akka Team napisał: > > Hi Marek, > > This is interesting. > > In our tests we have a special tool called Coroner ( > https://github.com/akka/akka/blob/master/akka-testkit/src/test/scala/akka/testkit/Coroner.scala) > > which actually checks the number of threads at the beginning and end of the > tests. Almost all of our tests extend AkkaSpec which uses this feature ( > https://github.com/akka/akka/blob/master/akka-testkit/src/test/scala/akka/testkit/AkkaSpec.scala > ). > > It has found no thread leaks so far, but we cannot exclude it completely. > The code snippets you pasted are unfortunately not enough for me to > investigate the issue. Can you actually share a standalone test case that I > can use to investigate further? > > -Endre > > > > On Mon, Sep 7, 2015 at 12:33 PM, Marek Żebrowski <[email protected] > <javascript:>> wrote: > >> I'm using AkkaSystem in a test. >> system config has enabled remoting >> >> akka { >> actor { >> creation-timeout = 5s >> } >> remote { >> enabled-transports = ["akka.remote.netty.tcp"] >> netty.tcp { >> hostname = "localhost" >> port = 7337 >> } >> } >> cluster { >> auto-join = off >> } >> } >> >> >> I try to shutdown system gracefully (afterAll function in ScalaTest, but >> it's irrelevant): >> >> verride def afterAll = { >> super.afterAll >> if (startCluster) { >> val cluster = Cluster(system) >> cluster leave cluster.selfAddress >> var counter = 200 >> while (cluster.isTerminated == false && counter >= 0) { >> Thread.sleep(50) >> counter = counter - 1 >> } >> } >> TestKit.shutdownActorSystem(system, verifySystemShutdown = true) >> } >> >> This seems to work ok, I get messages in the log: >> >> >> 12:23:45.846 INFO a.r.RemoteActorRefProvider$RemotingTerminator: Shutting >> down remote daemon. >> 12:23:45.847 INFO a.r.RemoteActorRefProvider$RemotingTerminator: Remote >> daemon shut down; proceeding with flushing remote transports. >> 12:23:45.871 INFO a.r.RemoteActorRefProvider$RemotingTerminator: Remoting >> shut down. >> >> >> But unfortunatelly IO threads are strill running >> >> "New I/O server boss #12" #119 prio=5 os_prio=31 tid=0x00007f8abadd5800 >> nid=0xb403 runnable [0x0000000146a0e000] >> java.lang.Thread.State: RUNNABLE >> at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method) >> at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198) >> at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:103) >> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) >> - locked <0x000000077e258828> (a sun.nio.ch.Util$2) >> - locked <0x000000077e258818> (a java.util.Collections$UnmodifiableSet) >> - locked <0x000000077e2586f8> (a sun.nio.ch.KQueueSelectorImpl) >> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) >> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) >> at >> org.jboss.netty.channel.socket.nio.NioServerBoss.select(NioServerBoss.java:163) >> at >> org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:212) >> at >> org.jboss.netty.channel.socket.nio.NioServerBoss.run(NioServerBoss.java:42) >> at >> org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) >> at >> org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> I can telnet 7337 port, and other threads are also running too >> >> "sgTestLiftActors-akka.actor.default-dispatcher-19" #126 prio=5 os_prio=31 >> tid=0x00007f8abad46800 nid=0xc203 waiting on condition [0x0000000147523000] >> java.lang.Thread.State: TIMED_WAITING (parking) >> at sun.misc.Unsafe.park(Native Method) >> - parking to wait for <0x000000077d67ab48> (a >> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinPool) >> at >> scala.concurrent.forkjoin.ForkJoinPool.idleAwaitWork(ForkJoinPool.java:2135) >> at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2067) >> at >> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) >> at >> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) >> >> >> It happens for both akka 2.3.12 and 2.3.13, when I run a single test using >> sbt test-only >> >> Behavior happens only if remoting is actually started in a test. Sometimes >> it is not, and IO thread is not a problem. >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - Reactive apps on the JVM > Blog: letitcrash.com > Twitter: @akkateam > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
