I'm having some difficulties with ActiveMQ. I have a legacy ActiveMQ server set up using version 5.5. I also have a newer messaging consumer running with version 5.8 that needs to consume messages from the legacy server. When I try to create a queue within the legacy server, I get no error messages, but no queue gets created either. I thought maybe there are some JMS options that are not supported with the older server, but I boiled down the JMS options to just the 'timeout=x' with no luck.
Is there any reason ActiveMQ 5.5 can not interact with 5.8?
No - there is no particular reason an ActiveMQ v5.5 server cannot interact with a v5.8 client. Of course it is an untested scenario and you'd forego bug fixes and new features but it should work. Always upgrade if you can. :)
Related
I hope to monitor ActiveMQ Artemis instances by configuring and using a SNMP connector by means of known Java properties
-Dcom.sun.management.snmp.interface=127.0.0.1 -Dcom.sun.management.snmp.port=50000 -Dcom.sun.management.snmp.acl=true -Dcom.sun.management.snmp.acl.file=/app/artemis/.snmp.acl
As ActiveMQ instances were monitored, but it does not work -- No error message is reported for Java SNMP properties, but no process is listening the chosen UDP port.
Is still possible to monitor ActiveMQ Artemis this way? And using JMX?
The SNMP agent was removed from Java 11 so that may be why it's not working for you.
However, you can certainly monitor ActiveMQ Artemis via JMX. See the documentation for more details on that.
If you just want to keep an eye on metrics you can use a metrics plugin. Using a plugin like the Prometheus metrics plugin would allow you to see exactly what's happening on the broker, set up alerts, etc.
I'm working in an rather old system that uses Java 6 and is deployed in GlassFish 2.1 server.
In that system I need to develop a message sender to ActiveMQ Artemis 2.17.0. Is there a way to achieve this?
I have been searching for solutions but the compatibility issues are a constant problem.
It is possible, but it's not going to be convenient. You can use any of the following that still support Java 6:
An older ActiveMQ Artemis client. I think the latest ActiveMQ Artemis client that could be built with Java 6 was 1.1.0, but the release was actually built with Java 7 so you'd have to build the client yourself.
An older HornetQ client. I'd recommend something in 2.3.x or 2.4.x. You might have to build one of those yourself as well.
An older OpenWire JMS client.
An older STOMP client.
I have a web application that has communicate with other Java web application throught JMS in Weblogic.
I read this answer:
How to connect Jms from PHP ?
I installed ActiveMQ and tried to use it.
But in the Weblogic we need "JMS_FACTORY" and "QUEUE_NAME".
I think it use t3 protocol.
When I want to use is ActiveMQ, it needs tcp protocol.
for example:
$stomp = new \Stomp('tcp://10.x.x.x:9700');
Is that possible to push messages in the Weblogic queue?
I think you mix API, wire protocol and client vs server in your question.
WebLogic JMS builds on java constructs all the way from Client to Server. If you really really need queue support I guess you need to create a PHP extension (in C/C++) that uses WebLogic C API (which in turn is a Java bridge). Maybe not smooth or bug free.
The easy way is to write a small WebLogic app that receives messages over HTTP and posts them to a queue. Or, if you can't touch the WebLogic installation, create a Standalone java app that you connect to your PHP in whatever way (HTTP, STOMP, MQTT, memory grid, files, whatever)
We have a requirment to connect to a JMS queue provided by an externally controlled IBM Websphere MQ server. Now, the easiest way to do it would be to include the Websphere MQ client into our application and just use the queue.
But IBM was so far not able to tell me about possible licensing costs of this setup. I saw forum posts and hints on IBM download pages that using the client is free of charge, but I do not know for sure. Maybe it's even the case, that the owner of the MQ server is allowed to provide us the client jar to use it for connecting to them, but again, I don't know for sure.
So I am evaluating the possibility to setup my own open source JMS server, for example an Apache ActiveMQ, and then bridge over to the Websphere MQ. For this, 2 questions rise up for me:
Technical solution: How would that be done exactly? I read a bit about bridging between JMS providers and something about the Apache Camel project, but have so far no exact idea how much work this will be and what needs exactly to be done.
Impacts: What should I bear in mind when implementing such a scenario? Do I still have to include the MQ client and such would not benefit over a direct connect? Are there any negative impacts compared to a direct connect that I must consider?
Update: Our application is a Java EE 6 application running on a JBosss 7.1. Concerning the MQ server version I have no information yet.
2nd Update: The MQ server version is 6.5.
The client to MQ is available for you to use; there's a license agreement to accept not a charge.
There are several options for how these client libraries could get to you practically.
You mention JMS is being used - within what container/environment is this? JavaSE/JavaEE/OSGi or something else.
JavaSE or the 'something else' would the JMS Client JARs.
JavaEE would need the IBM MQ Resource Adapter
OSGi would need the OSGi Bundles
In earlier versions of MQ there was the 'extended transnational client' that had a charge associated with it (pretty much the same as a full server) but that is no more.
As this is for JBOSS 7.1 - the solution would be to follow this link
http://www-01.ibm.com/support/docview.wss?uid=swg21633761
.. and download the IBM MQ Resource Adapter directly from the instructions there... 7.5.0.4 has also been released this last week. Please consider this as downloading the MQCxxx support pac will give you too much. This download does have the license agreement to accept but it's the same as the one has been highlighted elsewhere. It does mention Liberty but it's the same RA that is supported for within JBOSS.
For information on configuring the RA inside JBOSS please look at
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031820_.htm
The version of the RA or JMS client code is not tightly coupled with the server version. Client or bindings.
You won't have any support apart from via the web; unless you get the company running the externally controlled server to raise it.
Edit: have added download links
Pasting from this page
Category 3 WebSphere MQ SupportPacs are supplied under the standard terms and conditions provided by the International Program License Agreement (IPLA) and thus, carry program defect service for WebSphere MQ customers. Please read the IPLA and LI files that accompany the SupportPac, to ensure you understand the conditions under which the SupportPac is provided.
If you encounter what you believe to be a defect with the SupportPac, and you have a current license for a WebSphere MQ server product, you may request Program Services by reporting the problem via the same defect reporting channel you employ for the WebSphere MQ server product(s) on which you are using the SupportPac. No proof of entitlement is required to use this SupportPac.
Service is available for the v7.5 version of this SupportPac for as long as the WebSphere MQ V7.5 server product is supported by service. Refer to the WebSphere product lifecycle pages for the relevant service information. It is only supported with MQ platforms which are themselves supported.
I am thinking text in bold indicates MQ Client is free.
WebSphere MQ Client has no licensing fees. The only fees (and I think they did away with this one) would have been for the XA client. The client download should come with Client for JMS, which is not the same as Client for Java (native IBM API in java). When you install the client, just check to ensure you have /java/ which will contain all of the dependent jars for connecting to IBM MQ.
I would highly suggest using Apache Camel as your bridge vs creatng your own. You can then choose to run the camel route inside of the ActiveMQ JVM or other supported container. Most of the work will be learning how to do it the first time. Once you have it set up you will realize the time savings and power of Apache Camel.
No matter what you need MQ Client. MQ Server includes MQ Client, so if all this is on the same host you have nothing else to install. If by direct connect you mean bindings mode vs client mode, then yes, bindings mode is always the most efficient. And on the flip side, if you run your route in your broker you can take advantage of the VM transport.
The main considerations you need to think about for messages bridging between ActiveMQ and WebSphere MQ are really typical messaging questions. For example, Do you need the message to survive an outtage? If so, then consider using local transactions with your routes.
Bridging an ActiveMQ broker with a WebSphere MQ queue manager requires the same client libraries as a direct connection.
You are correct that you can pretty easy setup such a bridge using Apache Camel, that comes bundled with ActiveMQ.
One possible benefit from having a local broker as a buffer might be that your application can rely on a broker that is up and controlled by you. The remote/external controlled WebSphere MQ might be taken down for maint. by external parties or the network might be shaky. Of course, your application can handle such things using logic and rescheduled transmissions but it's far easier to set up a Camel route in ActiveMQ to do that and focus your logic in the application to do business logic.
I have an application that was written on JBoss 3.2.5 and I am tasked with migrating it to JBoss 5.
I am unable to deploy the application because it relies on JBoss MQ, which I read has been replaced by JBoss Messaging.
Is there any way I can get the app to work on JBoss 5 without making any code changes? Config changes are OK.
Actually JBoss Messaging is already being replaced by HornetQ.
In JBoss Application Sever 6.0, HornetQ will be the default messaging provider.
http://jboss.org/hornetq/
Is there any way I can get the app to
work on JBoss 5 without making any
code changes? Config changes are OK.
Assuming that your code is written to the JMS API, then yes, you probably can. However, don't underestimate how different JBossMQ is from JBossMessaging, the configuration is completely different.
Depending on how hard your app pushes the JMS API, you may get behavioural differences, but the odds are you'll be fine, as long as you can reconfigure JBossMessages within JBoss5 appropriately.
Another option is to move to JBoss 4.2, which still has JBossMQ, but is miles ahead of JBoss 3.2. Much of the functionality that JBoss5 gives you can be done with JBoss 4 (e.g. it has partial JavaEE 5 support).
JBossMQ will be replaced by JBoss Messaging in JBoss AS 5.0.
A good starting point to find out how to migrate would be JBossMQ