1
resposta

Conexão e Sessão com vida Longa é boa prática? o código para fecha-los é necessário?

No código temos o seguinte trecho:

MessageConsumer consumer = session.createDurableSubscriber(topico, "assinatura");

        consumer.setMessageListener(new MessageListener() {

            @Override
            public void onMessage(Message message) {

                TextMessage textMessage = (TextMessage)message;

                try {
                    System.out.println(textMessage.getText());
                } catch (JMSException e) {
                    e.printStackTrace();
                }
            }

        });


        new Scanner(System.in).nextLine();

        session.close();
        connection.close();
        context.close();
    }

O new Scanner(System.in).nextLine(); serve para travar a execução do programa e manter a conexão e a seção abertos para que o consumidor fique ouvindo as mensagens que vão chegando correto? em tese os métodos session.close(),connection.close() e context.close(); não serão chamados enquanto o programa estiver executando, então a dúvida é se é necessário este código estar ai? não poderia simplesmente tirar eles daí?

Outra coisa, não sei como é o funcionamento dos MDB, mas estou usando activemq dentro de uma aplicação em um wildfly, e pra não ter que ficar configurando o servidor que eu não tenho acesso, estou utilizando a abordagem do curso, então, é uma boa prática manter a conexão e a sessão abeertos por toda a vida da aplicação? pelo menos no caso dos consumidores?

Uma outra coisa é a linha new Scanner(System.in).nextLine(); isso dá erro quando rodo no wildfly(estou rodando o consumer em uma thread separada), existe alguma outra forma de segurar a execução da aplicação? eu utilizei um Thread.sleep para testar e funcionou, mas isso é inviável na prática

1 resposta

Olá Ricardo, tudo bem amigo?

Manter a conexão e a sessão abertas por toda a vida da aplicação pode ser uma prática válida, especialmente em cenários onde há um consumo constante de mensagens. Isso evita o overhead de abrir e fechar a conexão repetidamente, o que pode ter impacto no desempenho. No entanto, é importante ressaltar que essa abordagem deve ser utilizada com cuidado e considerando os requisitos e características específicas do seu sistema. Em alguns casos, pode ser necessário fechar a conexão e a sessão em momentos específicos, como ao finalizar uma tarefa ou encerrar a aplicação.

No código fornecido, o trecho new Scanner(System.in).nextLine(); é utilizado para manter a execução do programa em um estado bloqueado e permitir que o consumidor continue ouvindo as mensagens que chegam. Ele serve como uma forma simples de controlar o fluxo da aplicação.

Se você não precisa dessa funcionalidade de bloquear a execução, é possível remover as linhas session.close(), connection.close() e context.close() sem problemas. No entanto, certifique-se de que em outros pontos do seu código, onde for necessário encerrar a conexão ou sessão, você faça isso corretamente para evitar vazamentos de recursos.

Quanto à alternativa para substituir new Scanner(System.in).nextLine(); no Wildfly, você pode utilizar uma solução mais adequada, como aguardar a execução por um tempo específico ou utilizar mecanismos de controle de threads, como CountDownLatch, para sincronizar a execução do programa. Por exemplo, você pode definir um CountDownLatch com um contador de 1 e chamar o método await() para aguardar a contagem regressiva. Ao atingir o ponto em que você deseja encerrar a execução, você pode chamar o método countDown() para liberar a espera. Por exemplo:

CountDownLatch latch = new CountDownLatch(1);

// ...

latch.await(); // Aguarda a contagem regressiva

// ...

latch.countDown(); // Libera a espera e permite a finalização da execução

Em relação ao uso de MDB (Message-Driven Beans) no Wildfly, eles são uma alternativa para a implementação de consumidores assíncronos de mensagens JMS em um servidor de aplicação Java EE, como o Wildfly. Os MDBs permitem que o servidor gerencie a conexão, sessão e ciclo de vida do consumidor automaticamente, o que pode simplificar o desenvolvimento e a configuração do código JMS.

Espero ter ajudado e bons estudos ;)