java.nio.channels.ClosedSelectorException

Apache's JIRA Issue Tracker | Steven Zhen Wu | 2 years ago
  1. 0

    On Mon, Apr 13, 2015 at 7:17 PM, Guozhang Wang <wangguoz@gmail.com> wrote: It is a valid problem and we should correct it as soon as possible, I'm with Ewen regarding the solution. On Mon, Apr 13, 2015 at 5:05 PM, Ewen Cheslack-Postava <ewen@confluent.io> wrote: > Steven, > > Looks like there is even more that could potentially be leaked -- since key > and value serializers are created and configured at the end, even the IO > thread allocated by the producer could leak. Given that, I think 1 isn't a > great option since, as you said, it doesn't really address the underlying > issue. > > 3 strikes me as bad from a user experience perspective. It's true we might > want to introduce additional constructors to make testing easier, but the > more components I need to allocate myself and inject into the producer's > constructor, the worse the default experience is. And since you would have > to inject the dependencies to get correct, non-leaking behavior, it will > always be more code than previously (and a backwards incompatible change). > Additionally, the code creating a the producer would have be more > complicated since it would have to deal with the cleanup carefully whereas > it previously just had to deal with the exception. Besides, for testing > specifically, you can avoid exposing more constructors just for testing by > using something like PowerMock that let you mock private methods. That > requires a bit of code reorganization, but doesn't affect the public > interface at all. > > So my take is that a variant of 2 is probably best. I'd probably do two > things. First, make close() safe to call even if some fields haven't been > initialized, which presumably just means checking for null fields. (You > might also want to figure out if all the methods close() calls are > idempotent and decide whether some fields should be marked non-final and > cleared to null when close() is called). Second, add the try/catch as you > suggested, but just use close(). > > -Ewen > > > On Mon, Apr 13, 2015 at 3:53 PM, Steven Wu <stevenz3wu@gmail.com> wrote: > > > Here is the resource leak problem that we have encountered when 0.8.2 > java > > KafkaProducer failed in constructor. here is the code snippet of > > KafkaProducer to illustrate the problem. > > > > ------------------------------- > > public KafkaProducer(ProducerConfig config, Serializer<K> keySerializer, > > Serializer<V> valueSerializer) { > > > > // create metrcis reporter via reflection > > List<MetricsReporter> reporters = > > > > > config.getConfiguredInstances(ProducerConfig.METRIC_REPORTER_CLASSES_CONFIG, > > MetricsReporter.class); > > > > // validate bootstrap servers > > List<InetSocketAddress> addresses = > > > > > ClientUtils.parseAndValidateAddresses(config.getList(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG)); > > > > } > > ------------------------------- > > > > let's say MyMetricsReporter creates a thread in constructor. if hostname > > validation threw an exception, constructor won't call the close method of > > MyMetricsReporter to clean up the resource. as a result, we created > thread > > leak issue. this becomes worse when we try to auto recovery (i.e. keep > > creating KafkaProducer again -> failing again -> more thread leaks). > > > > there are multiple options of fixing this. > > > > 1) just move the hostname validation to the beginning. but this is only > fix > > one symtom. it didn't fix the fundamental problem. what if some other > lines > > throw an exception. > > > > 2) use try-catch. in the catch section, try to call close methods for any > > non-null objects constructed so far. > > > > 3) explicitly declare the dependency in the constructor. this way, when > > KafkaProducer threw an exception, I can call close method of metrics > > reporters for releasing resources. > > KafkaProducer(..., List<MetricsReporter> reporters) > > we don't have to dependency injection framework. but generally hiding > > dependency is a bad coding practice. it is also hard to plug in mocks for > > dependencies. this is probably the most intrusive change. > > > > I am willing to submit a patch. but like to hear your opinions on how we > > should fix the issue. > > > > Thanks, > > Steven > > > > > > -- > Thanks, > Ewen > -- -- Guozhang

    Apache's JIRA Issue Tracker | 2 years ago | Steven Zhen Wu
    java.nio.channels.ClosedSelectorException
  2. 0

    [GLASSFISH-11962] Starting embedded server hangs with TimeoutException - Java.net JIRA

    java.net | 5 months ago
    java.nio.channels.ClosedSelectorException
  3. 0

    Halting this cluster node due to unrecoverable service failure

    Oracle Community | 6 years ago | MagnusE
    java.nio.channels.ClosedSelectorException
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Starting embedded server hangs for 2-3 mins with java.util.concurrent.TimeoutException. Apparently this is related to grizzly issue according to Jerome and Alexey. startDomainEmbedded: [echo] === EMBEDDED STARTING === [glassfish-embedded-start] Starting server [glassfish-embedded-start] May 20, 2010 11:20:25 AM com.sun.logging.LogDomains$1 log [glassfish-embedded-start] INFO: GlassFish v3 (Amy-private) startup time : Embedded(1002ms) startup services(593ms) total(1595ms) [glassfish-embedded-start] May 20, 2010 11:20:25 AM com.sun.logging.LogDomains$1 log [glassfish-embedded-start] INFO: enterprise_used_delegate_name [glassfish-embedded-start] May 20, 2010 11:20:25 AM com.sun.logging.LogDomains$1 log [glassfish-embedded-start] INFO: JMXStartupService: JMXConnector system is disabled, skipping. [glassfish-embedded-start] May 20, 2010 11:20:25 AM AppServerStartup run [glassfish-embedded-start] INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started [glassfish-embedded-start] May 20, 2010 11:20:25 AM org.hibernate.validator.util.Version <clinit> [glassfish-embedded-start] INFO: Hibernate Validator null [glassfish-embedded-start] May 20, 2010 11:20:25 AM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA [glassfish-embedded-start] INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver. [glassfish-embedded-start] May 20, 2010 11:20:26 AM com.sun.grizzly.Controller logVersion [glassfish-embedded-start] INFO: Starting Grizzly Framework 1.9.19-beta3 - Thu May 20 11:20:26 PDT 2010 [glassfish-embedded-start] May 20, 2010 11:20:26 AM com.sun.grizzly.Controller logVersion [glassfish-embedded-start] INFO: Starting Grizzly Framework 1.9.19-beta3 - Thu May 20 11:20:26 PDT 2010 [glassfish-embedded-start] May 20, 2010 11:23:46 AM org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1 call [glassfish-embedded-start] SEVERE: Config Listener notification took too long [glassfish-embedded-start] java.util.concurrent.TimeoutException [glassfish-embedded-start] at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) [glassfish-embedded-start] at java.util.concurrent.FutureTask.get(FutureTask.java:91) [glassfish-embedded-start] at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1.call(Transactions.java:255) [glassfish-embedded-start] at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1.call(Transactions.java:236) [glassfish-embedded-start] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [glassfish-embedded-start] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [glassfish-embedded-start] at org.jvnet.hk2.config.Transactions$Notifier$1.run(Transactions.java:158) [glassfish-embedded-start] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [glassfish-embedded-start] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [glassfish-embedded-start] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [glassfish-embedded-start] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [glassfish-embedded-start] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [glassfish-embedded-start] at java.lang.Thread.run(Thread.java:637) May 20, 2010 11:27:18 AM com.sun.grizzly.SelectorHandlerRunner handleSelectException WARNING: Selector was unexpectedly closed. java.nio.channels.ClosedSelectorException at sun.nio.ch.SelectorImpl.selectedKeys(SelectorImpl.java:57) at com.sun.grizzly.TCPSelectorHandler.select(TCPSelectorHandler.java:513) at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:185) at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) May 20, 2010 11:27:18 AM com.sun.grizzly.SelectorHandlerRunner handleSelectException SEVERE: Can not workaround Selector close. java.nio.channels.ClosedSelectorException at sun.nio.ch.SelectorImpl.keys(SelectorImpl.java:51) at com.sun.grizzly.SelectorHandlerRunner.switchToNewSelector(SelectorHandlerRunner.java:507) at com.sun.grizzly.SelectorHandlerRunner.handleSelectException(SelectorHandlerRunner.java:414) at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:208) at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637)

    Java.net JIRA | 7 years ago | Amy Roh
    java.nio.channels.ClosedSelectorException
  6. 0

    spring with coherence cache deploy issue

    Oracle Community | 3 years ago | ppssrr
    java.nio.channels.ClosedSelectorException

    2 unregistered visitors
    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.nio.channels.ClosedSelectorException

      No message provided

      at sun.nio.ch.SelectorImpl.keys()
    2. Java RT
      SelectorImpl.keys
      1. sun.nio.ch.SelectorImpl.keys(SelectorImpl.java:51)
      1 frame
    3. Apache Kafka
      KafkaProducer.close
      1. org.apache.kafka.common.network.Selector.close(Selector.java:175)
      2. org.apache.kafka.clients.NetworkClient.close(NetworkClient.java:319)
      3. org.apache.kafka.clients.ClientUtils.closeQuietly(ClientUtils.java:57)
      4. org.apache.kafka.clients.producer.KafkaProducer.close(KafkaProducer.java:549)
      4 frames