Блог

Главная - Вопросы по программированию - Отвечает ли сборщик мусора java за освобождение JMS-соединения после connection.close()

Отвечает ли сборщик мусора java за освобождение JMS-соединения после connection.close()

#java #garbage-collection #connection #jms #release

#java #сбор мусора #подключение #jms #освободить

Вопрос:

Я использую GlassFish JMS ConnectionFactory. Соединение закрыто окончательно. и максимальный размер пула установлен равным 5.

Тестовый пример: я постоянно отправлял 10 сообщений в течение 3 секунд от invoker ().

Результат: первые 5 сообщений отправлены успешно, и последующему сообщению 6 не удалось выделить больше соединений. Это означает, что все предыдущие 5 соединений все еще были открыты.

Вопрос 1: Сколько времени требуется для освобождения опроса соединения после connection.close ()?

Вопрос 2: Отвечает ли сборщик мусора за освобождение соединения после JMS connection.close()?

Это мой простой клиент сообщений, который отправляет сообщения в очередь

private void invoker (идентификатор строки){

     Connection connection = null;
    Session session = null;
    MessageProducer messageProducer = null;
    TextMessage message = null;
    try {
        connection = connectionFactory.createConnection();
        session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        messageProducer = session.createProducer(successfulQueue);
        String msg = id;
        message = session.createTextMessage(msg);
        messageProducer.send(message);
        log.info("Successful message is Sent to ProcessQueue: ["   msg   "]");
    }
    catch (Exception e) {
        log.error(e);
    }
    finally {
        if (messageProducer != null) {
            try {
                messageProducer.close();
            }
            catch (JMSException e) {
                log.error(e);
            }
        }
        if (session != null) {
            try {
                session.close();
            }
            catch (JMSException e) {
                log.error(e);
            }
        }
        if (connection != null) {
            try {
                connection.close();
            }
            catch (JMSException e) {
                log.error(e);
            }
        }
    }

Комментарии:

1. Это Garbage Collector не JMS Connection Releaser , так что попробуйте угадать.

2. Спасибо за ответ, итак, каков наилучший подход, чтобы избежать сбоя выделения?

3. Ну, я подозреваю, что вы делаете много неправильных вещей. Прежде всего, вы говорите, что это ваше MDB , что неверно. Для обработки сообщения выполняется компонент, управляемый сообщениями. Ваш код не обрабатывает сообщения, он отправляет сообщение.

4. Отмечено с благодарностью. Просто чтобы внести изменения в мой пост, это простой клиент сообщений, который отправляет сообщения в очередь 🙂

Ответ №1:

Ответ на ваш 2-й вопрос заключается в том, что соединение не закрывается GC, но вместо этого фоновый процесс, который поддерживает соединение, прерывается connection.close() (О том, как работает GC, читайте:https://www.quora.com/How-does-garbage-collection-work-in-the-JVM )

Рекомендация: Попробуйте использовать PooledConnectionFactory и выполните .stop() для того же самого, кроме connection.close

     @Override
    public void contextDestroyed(ServletContextEvent arg0) {

    if (connection != null || pcf != null) try {
          connection.close();
    //pcf.stop();
    }
    catch (JMSException e) {
         //log
    }