как я могу предотвратить выход моего jvm при открытом соединении с клиентом netty? - PullRequest
Новая
       28

как я могу предотвратить выход моего jvm при открытом соединении с клиентом netty?

0 голосов
/ 01 февраля 2012

У меня есть API, который использует netty для открытия клиентского соединения с tcp-сервером.Сервер может отправлять данные клиенту в любое время.Я сталкиваюсь со следующим сценарием:

  1. Клиент подключается к серверу
  2. Отправляет данные на сервер
  3. Отключается, и JVM существует (сначала не уверен, что произойдет)

Это то, что я ожидаю:

  1. Клиент подключается к серверу
  2. Отправляет данные на сервер
  3. Клиент просто держит соединения открытыми, ожидаяполучать данные или отправлять данные пользователю клиентского API.

Это схема моего метода подключения (очевидно, что вокруг него гораздо больший API):

``` 

public FIXClient connect(String host, int port) throws Throwable {
    ...
    ChannelPipeline pipe = org.jboss.netty.channel.Channels.pipeline(...);

    ChannelFactory factory = new NioClientSocketChannelFactory(
                Executors.newCachedThreadPool(),
                Executors.newCachedThreadPool());

    ClientBootstrap bootstrap = new ClientBootstrap(factory);
    bootstrap.setPipeline(pipe);

    bootstrap.setOption("tcpNoDelay", true);
    bootstrap.setOption("keepAlive", true);

    ChannelFuture future = bootstrap.connect(new InetSocketAddress(host, port));

    //forcing the connect call to block
    //don't want clients to deal with async connect calls
    future.awaitUninterruptibly();

    if(future.isSuccess()){
        this.channel = future.getChannel();
        //channel.getCloseFuture();//TODO notifies whenever channel closes
    }
    else{
        throw future.getCause();//wrap this in a more specific exception
    }

    return this;
}

`` `

Ответы [ 2 ]

2 голосов
/ 01 июня 2012

Есть несколько способов сделать это, но я заметил, что с этим кодом: 

ChannelFactory factory = new NioClientSocketChannelFactory(
                Executors.newCachedThreadPool(),
                Executors.newCachedThreadPool());

... если вы установили успешное соединение, ваша JVM не будет отключаться сама по себе в течение некоторого времени, пока вы не принудите его (например, kill) или пока вы не вызовете releaseExternalResources () на вашем канале завод. Это потому что:

  • Потоки, созданные Executors.newCachedThreadPool () являются nonDaemon потоками.
  • Как минимум 1 поток будет создан после отправки запроса на подключение.
  • Кэшированные потоки пула потоков имеют время поддержания активности 60 секунд, то есть они не уходят, пока они не простаивают в течение 60 секунд, так что это будет 60 секунд после вашего соединения и отправить (при условии, что они оба выполнены).

Так что я не уверен, правильно ли вы диагностируете проблему. Сказав это, я рекомендую вам выполнить задачу следующим образом:

  1. После загрузки по методу main (в потоке main )
  2. Теперь запустите все вашу актуальную полезную работу в новых темах.
  3. После запуска полезных потоков в потоке main вызовите Thread.currentThread (). Join () . Поскольку main всегда не относится к dameon, вы убедились, что JVM не отключится, пока вы не будете готовы и готовы.
  4. В какой-то момент, если вы не захотите до убить -9 JVM в качестве стратегии выключения, вы захотите контролируемое отключение, поэтому вы можете добавить крюк выключения , чтобы отключить Netty, а затем прервать поток main .

Надеюсь, это полезно.

2 голосов
/ 01 февраля 2012

Это не имеет ничего общего с netty ... Вы должны убедиться, что ваш "основной" метод не будет существовать, если вы вызываете его оттуда. В противном случае это работа контейнера.

...