I have a new install of ActiveMQ Artemis on a local virtual machine using Ubuntu 18.04. I'm trying to connect to it with a JMS client called QueueExplorer.
Cannot read queues from machine 192.168.1.13/ (ActiveMQ).
StackTrace: Cogin.ActiveMQ.AMQException: Could not connect to ActiveMQ: Unable to connect to the remote server
at Cogin.ActiveMQ.Internal.JolokiaConnection.SendJsonRequest(String uriString, JToken requestJson)
at Cogin.ActiveMQ.Internal.JolokiaConnection.RequestBrokerName()
at Cogin.ActiveMQ.Internal.JolokiaRequest.GetMBeanObject(AMQMachineItem machine)
at Cogin.ActiveMQ.Internal.JolokiaConnection.Execute(JolokiaRequest request)
at Cogin.ActiveMQ.Internal.AMQBrokerProxy.GetBrokerInfo(IWorker worker)
at Cogin.ActiveMQ.Services.AMQBrokerService.GetQueuesTree(IWorker worker, Boolean showNonWritableQueues)
at a8.a.e(IWorker A_0)
at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ab.a.e()
Version: QueueExplorer Standard 4.3.15.26129 .Net Framework Version: 4.8.0 OS: Windows 10
I can ping the system successfully. The firewall is not enabled, and I can reach the web console. I followed this guide for setting it up, but I think I'm missing something. QueueExplorer needs Jolokia and OpenWire. The web console uses Jolokia, but the error in QueueExplorer complains about it.
When connecting to ActiveMQ with QueueExplorer, I didn't need to make any configuration changes. Are there additional steps in Artemis to allow a client to connect?
It's impossible to say with 100% certainty what the problem is since QueueExplorer is closed source software as far as I can tell. However, I can say with certainty that ActiveMQ Artemis does support OpenWire and it ships with Jolokia to expose its management beans (i.e. MBeans) via HTTP.
I believe the issue is that QueueExplorer expects to find in ActiveMQ Artemis the same MBeans as ActiveMQ 5.x and that simply isn't the case. While ActiveMQ Artemis supports many of the same features and functionality as ActiveMQ 5.x it is a fundamentally different architecture under the covers which is designed to provide a much higher level of performance and a protocol/API agnostic addressing model.
I believe the only solution here would be for the author(s) of QueueExplorer to update it to work with the ActiveMQ Artemis MBeans.
Related
I wonder if it is possible to configure message redelivery on the client side. I have read the ActiveMQ Artemis docs and have not found any information about this feature. So I made a conclusion that there is no opportunity to configure message redelivery on the client side. The only place to configure message redelivery is the broker.xml file. Am I right about it?
By the way I can configure the connection to ActiveMQ Artemis by using broker URL params or by application.yml since I using Spring Boot 2.x.
ActiveMQ Artemis supports AMQP, STOMP, MQTT, OpenWire, etc. Many clients exist for these protocols written in lots of different languages across all kinds of platforms. Whether or not a given client supports client-side redelivery is really up to the client itself. You don't specify which client you're using so it's impossible to give you a specific yes/no answer.
However, I can say that ActiveMQ Artemis ships a JMS client implementation which uses the core protocol. That client does not support client-side redelivery. However, the OpenWire JMS client shipped with ActiveMQ "Classic" does support client-side redelivery, and it can be used with ActiveMQ Artemis as well.
I am trying install ActiveMQ Browser, and I wanted to connect with my ActiveMQ Artemis server. How do we configure that?
I assume you're talking about this ActiveMQ Browser GUI tool.
If that assumption is correct then there's no way to integrate it with ActiveMQ Artemis as it's hard-coded to use the specific JMX management beans from ActiveMQ 5.x.
I recommend you use the ActiveMQ Artemis web console. It has a rich set of functionality that should cover most of the use-cases you're interested in. Among other things, it will allow you to:
Send new messages to addresses.
Delete messages.
Move messages to another address.
Create or delete addresses & queues.
Shutdown broker.
etc.
In case of any network issues or during triage some other issue, I would like to enable logging in the ActiveMQ Artemis broker (2.6.1) without restarting the broker to get more logging.
Currently I'm restarting the broker after enabling/disabling logging in logging.properties
logger.level=DEBUG
In ActiveMQ 5.x there is a JMX operation exposed (as mentioned in https://activemq.apache.org/how-do-i-change-the-logging). I couldn't find similar one for Artemis.
The version of ActiveMQ Artemis you're using doesn't support reloading logging configuration at runtime. This functionality was implemented via ARTEMIS-2121 so you'll need to move to 2.6.4 or 2.7.0 to get it.
Once you update your logging.properties the broker will reload it and a message will be logged that the logging configuration was reloaded. By default it may take up to 5 seconds to reload (based on the configuration-file-refresh-period in broker.xml which defaults to 5000 milliseconds).
I recently had to rollback from WF13 to WF11 due to a regression in one of the dependencies.
Now I am trying to get the AMQP protocol to work on WildFly 11's messaging system. I am running a high availability setup with two nodes. Each of the node has a message consumer locally. This message consumer connects through AMQP1. I've added io.netty as a dependency to the org/apache/activemq/artemis/protocol/amqp module and updated org/apache/qpid to get the AMQP protocol to work (see also WFLY-7823). Now my AMQP message consumer works fine, but it seems to receive messages always exactly twice, and it appears to be even in the same frame. This happens on the same node (the other node receives messages through the bridge if the message isn't handled locally in the first place). So on one node and one queue consumer, I receive every message exactly twice, at the very same instant, before I even got to send an ACK/NACK for the first message I received.
I don't remember seeing this issue on WildFly 13.
Are there any known regressions regarding how messages are sent through the remote connectors? Perhaps an issue in the AMQP protocol? Or could it be a compatibility issue with the updated version of qtip?
For what it's worth Wildfly only uses ActiveMQ Artemis to fulfill their need for a JMS implementation (i.e. a traditional part of Java EE). I don't believe Wildfly has any real interest in other protocols or APIs aside from JMS.
My understanding here is that if you need to support multi-protocol message use-cases you should likely be using a standalone broker. I believe this is why none of the other protocols which Artemis supports (e.g. AMQP, STOMP, MQTT, OpenWire) are enabled in Wildfly or have documentation on how to enable them (aside from the occasional forum post).
It's also worth noting that Wildfly 11 has Artemis 1.5.5 in it which is 10 releases or so behind the latest version (i.e. 2.6.2). Much work has been done on the AMQP implementation in those releases so I think you're best served by using a standalone version of Artemis rather than Artemis embedded in Wildfly.
I am new to Jboss fuse karaf(jboss-fuse-6.3) and activeMQ.
Currently I am accessing activeMq on localhost:61616, my question is what is more suitable way of using activeMQ - on same server(localhost:port) or can I use activeMQ hosted on remote server, which method is more fast and safe ?
Thanks.
If you are using it for dev purpose, then the most suitable way is to use the embedded one that comes with Fuse out of the box because it requires less maintenance.
However if you are asking about AMQ in production environment then most likely it should be highly available and able to survive crashes without data losses. In this case you need to think about some failover machanism, so the safer option is to use an external ActiveMQ broker or even better - a cluster of AMQ brokers. In this case the speed of message delivery and consumption depends on the network connectivity as well.
Also if we talk about speed you should consider where AMQ should store it's messages especially the undelivered ones. By default it comes with a file based DB KahaDB which can be changed. In both cases it's fast enough.
Wish you luck with the ESB!