Support for old remote HornetQ server

[scrublet]

My Wildfly needs to connect to a remote HornetQ 2.2.14 server. The connection fails (MDBs time out, an EJB sending a message times out). I have confirmed my ability to connect without code/config changes to a standalone 2.4.0 server, so backwards compatibility seems to be the issue.

I had a similar issue a long time ago with JBoss AS7 and HornetQ 2.2.8.EAP. At that time I was able to just upgrade the server, but that is an undesirable solution this time around. Is there anyway to somehow get my Wildfly to connect to an older server? And can anyone explain to me the backwards-compatibility and forwards-compatibility issues of HornetQ? It's not clear to me why the version of any JMS client would affect it's ability to connect to a JMS provider if following the JMS standard.

[jbertram]

In client/server applications backward compatibility is typically defined as the ability of an older client to connect to a newer server.  In other words, when a new server is released it is still compatible with the older, already-released clients.  Your use-case deals with forward compatibility where you want a newer client to talk to an older server.  See more here.

We've long worked to maintain backward compatibility but only recently sought to enable forward compatibility as that is generally the less common use-case.  See this JIRA.  Looks like the work we did there either doesn't cover the server you're using or something has broken between those changes and the release of 2.4.0.Final.

In any event, JMS is an API specification.  It doesn't define a wire protocol which means that JMS implementations (even different versions of the same implementation) are not necessarily compatible with each other.  For example, you can't take the ActiveMQ JMS client library and talk to HornetQ with it and vice-versa.

[scrublet]

UPDATE: Ignore this. This approach clearly isn't going to work.

Understood, thanks for the clarifications. What do you think the ramifications would be of trying to swap out the Wildfly 2.4.1 HornetQ libraries with 2.2.14? I may give that a try, but suppose it works for my use case...should I be concerned about any other potential problems that might not be readily apparent?

[jbertram]

A straight swap of libraries will almost certainly fail because the messaging subsystem is fairly tightly coupled with the version it ships with.  However, you could create a new module and use that module from your application.  The drawback here is that you wouldn't be able to use any JMS-specific container-managed resources which would rule out using a pooled-connection-factory (which is leveraged by MDBs).