ActiveMQ, JMX API - повторная отправка сообщений в очередь

Идея использовать JMX для отправки сообщений в очередь мне кажется очень странной.

Это делается через JMS API, а не через JMX.

Зачем тебе повторная оправка сообщения? Соль JMS в том, что оно берет на себя гарантированную доставку и само будет досылать сообщения повторно если это требуется - http://activemq.apache.org/redelivery-policy.html.

Идея использовать JMX для отправки сообщений в очередь мне кажется очень странной.

Это нужно для ручной отправки из веб-морды (самописный менеджер). Морда общается с работающей системой через JMX, поэтому вот так.

Зачем тебе повторная оправка сообщения?

Для тестов и случаев, когда в сопряженной системе что-то пошло не так, и наше сообщение не сгенерировало документов в системе, но из очереди пропало.

Что значит «отправить повторно»? Если просто опубликовать новое сообщение, то через JMX это возможно.

ActiveMQ работает в связке с UltraESB. Когда шина отправляет сообщения из очереди, то этот факт записывается в history в PostgreSQL для истории (которая отображается в веб-морде). Есть UUID сообщения, есть сами данные, которые были в сообщении. Иногда нужно взять какое-то сообщение из history, и пропихнуть заново в очередь в ActiveMQ.

Руками это делается через нативную веб-морду ActiveMQ, вот тут: https://i.imgur.com/liqlYFg.png

Для тестов - ок.

А вот на счет сопряженной системы not so fast. Если сопряженная система сказала на сообщение «ack», а потом сама продолбала это - это бага и ее надо фиксить, не надо говорить «ack». По хорошему надо бы это все завернуть в транзакцию и JTA должен сам сделать ACK когда положено, это то как все должно быть тру-ынтерпрайзненько.

Так вот, когда на такое сообщение не скажут ACK, ActiveMQ сама должна делать redelivery. В общем странный кейс у тебя.

Я боюсь тебе придется написать JMX бин, который умеет просто напросто новое сообщение засылать по имеющимся данным из истории.

И да, через JMX ничего не шлется, ты не общаешься с очередью через JMX. В твоем случае JMX - это морда к серваку, а не к очереди.

да, ок. с юз-кейсом разобрались. в JMX API ActiveMQ я нашел метод copyMessageTo. Делаю как-то так:

public Boolean enqueueMessage(String queueName, String messageId) {
        try {
            ObjectName name = new ObjectName("org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=" + queueName);
            QueueViewMBean queueMbean = (QueueViewMBean) MBeanServerInvocationHandler.newProxyInstance(this.getJmxConnector( ).getMBeanServerConnection( ), name, QueueViewMBean.class, true);

            return queueMbean.copyMessageTo(messageId, queueName);

        } catch (Exception ex) {
            System.out.println(ex.getMessage());
            createJmxConnection();
        }
        return false;
    }

Но оно возвращает мне false без выпадения в catch. Я не прав?

Но оно возвращает мне false без выпадения в catch. Я не прав?

Так мессаджа же нет как я понял. Стало быть нечего копировать. В одном из комментов выше говорится что весь контент мессаджа есть. Вот можно отправить его используя sendTextMessage (емнип так называется).

верно. получилось так:

public String enqueueMessage(String queueName, String messageText) {
        try {
            ObjectName name = new ObjectName("org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=" + queueName);
            QueueViewMBean destinationMBean = (QueueViewMBean) MBeanServerInvocationHandler.newProxyInstance(this.getJmxConnector( ).getMBeanServerConnection( ), name, QueueViewMBean.class, true);

            return destinationMBean.sendTextMessage(messageText);

        } catch (Exception ex) {
            System.out.println(ex.getMessage());
            createJmxConnection();
        }
        return null;
    }