Generic JMS provider for JBOSS AMQ - Forum - OpenEdge Development - Progress Community

Generic JMS provider for JBOSS AMQ

 Forum

Generic JMS provider for JBOSS AMQ

This question is answered

Jboss is redhat's distribution of apache active MQ (with apache artemis as the broker).

They are beginning to adopt a wire protocol called qpid. And they ship a jms client now that is built on qpid (once again, a redistribution of apache's "qpid-jms" which you can find here: https://qpid.apache.org/releases/qpid-jms-0.22.0/index.html)

I almost got this "qpid-jms" stuff working with OE 11.6 on Java 1.7. But the problem I am running into is that OE assumes there will be a method on the ConnectionFactory called "SetBrokerURL".  But there isn't a method by that name on the qpid-jms connection factory (JmsConnectionFactory).  Here is the error:

java.lang.Exception: org.apache.qpid.jms.JmsConnectionFactory class file not men
tioned correctly: java.lang.NoSuchMethodException: org.apache.qpid.jms.JmsConnec
tionFactory.setBrokerURL(java.lang.String)

It would be nice to know what the recommendation from Progress is for this situation.  I think the "SetBrokerURL" was common for method name for the other JMS connection factories but not an *actual* part of the JMS standard.    Instead of SetBrokerURL, the "qpid-jms" client appears to have a similar method called "setRemoteURI".

Please let me know what I should do.  I suppose I can downgrade to the old openwire-based activemq jms client because it still seems to work; but it is not included anymore with latest JBOSS AMQ downloads so I'm going way out on a limb to keep using it.

Perhaps Progress needs to do a more thorough job of allowing a variety of JMS clients.  I think there are only three that are listed in the whitepaper of "generic" jms options.  Or better yet, please consider adopting qpid messaging which is a lower level protocol (not simply an API)...  The "generic jms" approach is obviously not generic enough for the use of the "qpid-jms" API from Apache.

Verified Answer
  • Hi David,

    Apache Artemis internally uses JBOSS HornetQ messaging system which does not have setBrokerURL() method. Already this issue addressed in OE 11.7.1 release. From 11.7.1 onwards user is able to connect HornetQ and Apache Artemis brokers without any problem.

    So far we have certified the following MQ Providers.

    1. Apache ActiveMQ

    2. Apache Artemis

    3. JBOSS HornetQ

    4. IBM WebSphereMQ

    Hope this helps!!

    Thanks,

    Anand.

All Replies
  • Hi David,

    Apache Artemis internally uses JBOSS HornetQ messaging system which does not have setBrokerURL() method. Already this issue addressed in OE 11.7.1 release. From 11.7.1 onwards user is able to connect HornetQ and Apache Artemis brokers without any problem.

    So far we have certified the following MQ Providers.

    1. Apache ActiveMQ

    2. Apache Artemis

    3. JBOSS HornetQ

    4. IBM WebSphereMQ

    Hope this helps!!

    Thanks,

    Anand.

  • Thanks for the quick feedback.  

    You left out Sonic MQ in your list of certified providers.  Did you kick them off the island?   You probably should, considering what they are charging for a support contract to do simple messaging. ;)

    What can we do to get this into 11.6 service pack 4 that is supposed to be released shortly?  We are a couple months away from a production upgrade to OE 11.6.4 (from OE 11.3) and we aren't likely to be using 11.7 for several years.

    Also, what did you change to allow for the use of Jboss?  Did you write your own custom connection factories that wrap around the "real" ones?  Or did you extend the jmsprovider configuration to allow us to specify the *method* names used for each of those different connection factories?  Or perhaps JBoss finally agreed to add your "setBrokerURL()" method to all of their JMS client libraries? ;)

    It is unfortunate that messaging/integration changes like this would require a full upgrade to the installation of OpenEdge...  I understand that Progress is adopting "agile" practices for developing new versions of OpenEdge; but it really doesn't seem very "agile" at all that we can't use the Jboss qpid-jms client until after we upgrade to 11.7.1 - several years from now.  This type of change (switching messaging client versions) would not be so difficult for us to make in some other ecosystems like .Net or Java.  

    Depending on what you had to do to get Jboss up and running, we would be very open to attempting a similar thing on 11.6.  Please let me know.

  • Many still use SonicMQ.

  • SonicMQ from Aurea Software is alive and well. Sometimes when we think of support for "generic" JMS providers, we overlook SonicMQ as it adds additional value like guaranteed message delivery on top of the "generic" JMS standard. But clearly it is on our list of supported JMS vendors.

    We have not tested the Qpid JMS Client (we are not able to test every JMS provider in the marketplace proactively). It is based on the AMQP (Advanced Message Queuing Protocol), which specifies the wire protocol used when sending messages. It is JMS compliant, so it could/should be something that our generic JMS adapter can handle. Like other JMS providers that we have not tested but that our customers are interested in using, we will look at issues that come up and do our best to resolve them. It would be best to raise this as a bug with our Technical Support team to get this looked at "officially".

    A comment on "agile"- we do follow the Agile development methodology, and we do have examples where we have rolled out new capabilities rather quickly. Our customer base in general is not interested or equipped to take on a continuous stream of new features that a pure Agile methodology could supply- we heard that loud and clear when we did 3 releases in one 13-month period (11.1, 11.2 and 11.3). While we are now on a roughly annual release schedule, we can and do put enhancements into selected Service Packs as needed by our customers. In this particular case, the issue is likely to be considered a bug vs. a feature enhancement, which gives us more flexibility in resolving the issue (including the possibility of a Hot Fix if warranted by the circumstances).

  • Rob, thanks for the feedback.  I really appreciate it.  

    There are a variety of things that make it hard to do messaging in OE, but I see that I should probably work with tech support.  Another issue with OE messaging is that many JMS providers are only supporting the Java 8 JRE and OE 11.6 is still shipping Java 7 by default (I learned that OE system admins are allowed to upgrade to 8 on their own but I suspect many of them wouldn't or couldn't).  I think Oracle itself stopped offering Java 7 in mid 2015.

    Provided that we address the Java JRE issue first, do you think a custom JDNI admin object finder would help me get "qpid-jms" up and running on 11.6?  I saw stuff about this elsewhere (community.progress.com/.../24580 ).  I think the JDNI object finder avoids the need for specially named methods like "setBrokerURL".  But this might be more work than we would want to tackle in-house, especially without full Progress support.  I really wish OE had a larger open source community where we could find existing OE/broker integrations for a larger set of JMS clients.  Or maybe Progress should start taking requests for new custom (free) messaging integrations, no matter what the version of OE is, or the back-end broker, provided that the client uses JMS.  I doubt it would get too far out of hand.

    However, now that AMQP is here, I think Progress OE may want to go back to the drawing board and revisit their approach to doing messaging ( aka the so-called "generic JMS" approach).  I was never that keen on the extra hops and infrastructure that OE puts in place to allow us to do messaging from ABL.  The "adapter/ubroker" approach was particularly ugly - we constantly had weird connectivity and configuration issues with that.  IMHO that thing adds no real functionality or value.  All it adds is extra configuration/management and, as a special bonus, it gives us an extra point of system-wide failure which will create widespread problems for every ABL client in the system that is unfortunate enough to be referencing it.  On the other hand the OE "clientconnect/symbiont" is more straight-forward but it is is not without problems.  Most of the problems are there because of the Java "symbiont" process overhead (memory use, startup delays, JavaTools configuration requirements, localized failures that can arise in a single ABL client/symbiont pair, etc.)

    With AMQP now available, Progress may be able to finally connect in a more native fashion to any broker that supports the protocol.  OE can finally bypass Java altogether.  It seems like a "no-brainer" for Progress to adopt AMQP, so I suppose they will get there after several more years.  I'll add it to the enhancement "ideas" list if its not already there....

    One of the more significant reasons why you might want to move ahead with AMQP sooner rather than later is because I understand heard that "clientconnect/symbiont" is NOT an option with OE PAS (probably because the messaging stuff was designed before Progress had invented multi-threaded ABL processes.)  Without "clientconnect" we would have no option than to revert to that "adapter/ubroker" thing which would be a major step backwards and open ourselves back up to system-wide messaging failures again.  That weird ubroker component simply makes a complex messaging environment that much more complex because of a superfluous/additional moving part.

  • We’ve been asking Progress for AMQP support too. So hopefully it won’t be several years away.