Hi,
I am not sure if any of you are faced with this situation.
In current 9.x SAG is not certifying JMS connectivity to MQ 8.0 and they simply don’t support for any issues. On the other hand, the MQ adapter 6.5 doesn’t support multi-instance queue manager. As a product vendor, they should be either certify JMS or support the multi-instance queue manager in the adapter. They are happy to throw a statement that they are not supporting these. This is a big risk for enterprises using JMS through WM for long.
Is it a deliberate move from their part to push UM? Any thoughts?
Cheers
Guna
Hi Guna,
please open an idea/feature request on Brainstorm for this.
Lets see what happens.
Regards,
Holger
Hi Holger,
That was already done. What I don’t understand is why SAG is not doing it by default when a lot companies are sure dependent on it. It is sad to see the fate of business critical resolutions are dependent on brainstorming.
Cheers
Guna
Hi,
but MQ 8.0 should be supported in general with exception to the points you have mentioned.
JMS should be supported anyway without being restricted to certain JNDI/JMS providers.
Regards,
Holger
We have been using JMS to connect to MQ 8.0 for the past few months in non-prod. Since SAG doesn’t provide any support on this, this is a huge risk. On the otherhand there is no alternate solution.
I am just wondeing how other SAG customers are dealing with this situation.
Cheers
Guna
Guna,
Just sharing my thoughts…
I understand from your initial post that, you want to use the feature of ‘multi instance queue manager’ of MQ 8.0. I was reading the below articles to understand how does that work…
[url]http://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q018140_.htm[/url]
[url]http://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q018370_.htm[/url]
[url]Using WebSphere MQ automatic client reconnection with the WebSphere MQ classes for JMS
This looks like a typical active/passive setup of MQ nodes, and both nodes points to the common storage and log files (similar to Broker active/passive setup with shared storage/SAN)
Is it possible to setup a VCS cluster that will redirect the requests to either of the node which is available and running? If that is possible, then you will get a single IP and PORT to which you need to establish the connectivity, which you can do so by using MQ Adapter 6.5 which is already supported to get connected to MQ 8.0.
Does it make sense to give this a try?
-Senthil
Hi Senthil,
Thanks for your time and suggestions. Active/Passive and multi-instance are a bit different. In multi-instance the queue manager will be running only on active node, the one which acquires NFS lock first. Other node will also be up and running. If there is a problem with the active node, it shuts down queue managers and releases lock, passive node takes over. Native MQ client & JMS clients are aware of this and reconnect when ever a failover happens.
Reg. the changes, I would be glad if this can be achievable. But this approach is not at all feasible in any enterprise. Typically there will be multiple MQ landscapes in the enterprise catering to different business units or OpCos. webMethods will only be a tiny JMS consumer/MQ client, typically accessing a couple of queue managers and queues. As a middleware, WM can never be able to dictate architecture changes and it shouldn’t be; its not possible though!
SAG might be fading out MQ support.
Cheers
Guna
Hi Guna,
what is common between the active/passive setup and multi-instance setup is the way clients accesses using the IP and port, hence I was suggesting this as a possible workaround. Though the second node is up/running in multi-instance approach, the second node will be in read-only & clients cannot connect to that. It will become read-write only when the other node goes down, so a restart (or some action) is performed to make the passive become active and clients can connect. There is always a delay in-between (similar to a active/passive setup of broker). In many of the enterprise, there will be a MQ farm with real active/active setup in place.
Having said this, I understand this would be a workaround and not the real solution! The real solution is to get IS certified with MQ 8.0 which I believe is already requested by AXA via brainstorm. You may check with the respective Product managers or through account team to know exactly when this will be available.
webMethods and MQ series both are completely different technologies solving different use-cases. I am not sure why you thought, webMethods is ‘dictating’ the architecture of MQ. It is just that, webMethods has not been certified with MQ 8.0 as it was not tested so far.
Hope you can get more assistance with the respective product managers via brainstorm.
My 2 cents.
Regards
Senthil