| Author |
Message
|
| Heba_MQ |
 Posted: Mon Oct 12, 2020 8:26 am Post subject: MQ Binding mode - 2 questions |
 |
|
Apprentice
Joined: 19 Apr 2020
Posts: 39
|
Dear All
For some reasons, project decided to move one small application that used to connect as a client to MQ server from its own server to the MQ Server itself...
The application used to connect via an MQI channel...
The question now is that, if the code will be moved to MQ server...will there be any use for the channel... Should I delete the MQI channel definition? I have never seen a binding mode before... that is why confused.
I believe the application should run under another Linux user other than mqm (hopefully)...Shall I also need to configure auth recs for that application user to access the queue manager and the MQ objects with the binding mode ?
Many Thanks for your help
Heba |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Mon Oct 12, 2020 2:05 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
The app can still connect via MQ Client if it is easier (no changes to app config). Performance will be not quite as good as Binding mode. Being on the same server, MQ Client does not need to pass through any network devices, so at least that latency is removed.
If the change to MQ Binding mode is taken, the app should always run as its own userid, never mqm. The minimum MQ auth profiles should be set up for that user principal (or more ideally, an appropriate group).
_________________
Glenn |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Oct 20, 2020 7:32 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
MQ consumers that connect to the queue manager in bindings mode or more likely to be impacted after an MQ upgrade or patch as we were when we went from MQ v7 to MQ v8 and from MQ v8 to MQ v9
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 20, 2020 3:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| belchman wrote: |
| MQ consumers that connect to the queue manager in bindings mode or more likely to be impacted after an MQ upgrade or patch as we were when we went from MQ v7 to MQ v8 and from MQ v8 to MQ v9 |
What was the impact? Was it assessed and tested before the upgrade?
_________________
Glenn |
|
| Back to top |
|
|
| belchman |
| Posted: Wed Oct 21, 2020 3:20 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
In this case, there were applications that had scoped the deprecated MQ libraries in their path. The deprecated binaries would get a java version mismatch when trying to interface with the new MQ server version.
In WebSphere, the MQ Install Root was the culprit. Apps on WAS that were bindings connect, use that variable and would get the same version mismatch.
It was tested in non-prod to identify which apps had the deprecated library affinity. We then had apps that did not require bindings connections to change to client mode. Those that must be in bindings mode, we had them source the new MQ libraries.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Oct 21, 2020 2:46 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Was it the curse of Java CLASSPATH ?
_________________
Glenn |
|
| Back to top |
|
|
| belchman |
| Posted: Thu Oct 22, 2020 3:34 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
No. It was the curse of the java in the old version of MQ client being say java 5, and the java in the MQ server being say java 6 or java 7. I cannot remember explicit details. In bindings mode, the java on the client and the java on the server have to be close enough in versioning to make them compatible.
For example, in WebSphere, it was using MQ client v7.1 in the WAS resource adapter. It was doing that up until around WASv8.5. That MQ client code would not work against MQv9. That meant that all apps hosted on WAS absolutely would not work with a bindings connection until the MQ_INSTALL_ROOT variable in Websphere was changed from pointing to the MQv8 libraries to point to the MQv9 libraries.
All of these compatibility problems are moot it you connect in client mode because you do not depend on the version of the server.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 26, 2020 7:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| belchman wrote: |
No. It was the curse of the java in the old version of MQ client being say java 5, and the java in the MQ server being say java 6 or java 7. I cannot remember explicit details. In bindings mode, the java on the client and the java on the server have to be close enough in versioning to make them compatible.
For example, in WebSphere, it was using MQ client v7.1 in the WAS resource adapter. It was doing that up until around WASv8.5. That MQ client code would not work against MQv9. That meant that all apps hosted on WAS absolutely would not work with a bindings connection until the MQ_INSTALL_ROOT variable in Websphere was changed from pointing to the MQv8 libraries to point to the MQv9 libraries.
All of these compatibility problems are moot it you connect in client mode because you do not depend on the version of the server. |
Version V8 vs V9 libraries should not matter, howerver you might want to have your java.library.path pointing to the correct V9 directory (/opt/mqm/v9/java/lib64) so that the correct libraries get invoked...
Of course your java version needs to also satisfy the minimum Java version for your MQ Version... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
