| Author |
Message
|
| brianb |
 Posted: Tue Dec 14, 2010 9:04 pm Post subject: MQv7 MI and bindings |
 |
|
Voyager
Joined: 12 May 2010
Posts: 85
|
Hi
If I have WMQv7 installed on my WAS6.1 server and am using bindings how would this work with Multi Instance ? any thoughts other than it won't  work arounds etc
My understanding is bindings must be local and once we fail over to the MI QM it would no longer be local ? |
|
| Back to top |
|
 |
| HubertKleinmanns |
| Posted: Tue Dec 14, 2010 11:01 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
brianb,
WMQ version 7.0.1 comes with multi-instance QMgrs AND client reconnect facilities. This means MQ clients would automatically reconnect to the same or another QMgr using a client channel definition table.
As far as I know the client libraries of the WebSphere Application Server are transactional (same as the XA client of WMQ). Should should ask WAS experts about this.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 15, 2010 12:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Correct, bindings must be local, so the work around is as Hubert suggests, convert the WAS connection to a client connection and use a CCDT file.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 15, 2010 1:06 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Auto client reconnect does not happen without either coding or config changes on the client side.
Also the queue manager must be ended with -r. It won't work with failures.
It also won't work unless the application is coded in certain languages.
All in all it is not a complete solution. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 15, 2010 3:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| It's not entirely clear why you would fail the qmgr over and not fail the was instance as well. |
|
| Back to top |
|
|
| brianb |
| Posted: Wed Dec 15, 2010 12:20 pm Post subject: MQ MI |
|
|
Voyager
Joined: 12 May 2010
Posts: 85
|
Hi mqjeff
Point taken but I am ignoring that Just got over trying to figure out how to failover Tomcat along with MQ and WMB got that working well. So now its onto WAS. The suggestion to use client connections is fine except I am looking at bindings to get rid of my current proxy server which handles client connections (keep clients channels from broker qm etc). So moving my application QM to the WAS server and using bindings with server channels to broker QM. Now if they would just make the broker HTTP listener more robust I could get rid of the tc server........on and on....
Anyway the MQ and WMB portion of this works great just all those other "fixes" type of crap make it challenging
I dont see WAS7 making this much easier either unless I go back to client connection ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 15, 2010 12:33 pm Post subject: Re: MQ MI |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| brianb wrote: |
Hi mqjeff
Point taken but I am ignoring that Just got over trying to figure out how to failover Tomcat along with MQ and WMB got that working well. So now its onto WAS. The suggestion to use client connections is fine except I am looking at bindings to get rid of my current proxy server which handles client connections (keep clients channels from broker qm etc). So moving my application QM to the WAS server and using bindings with server channels to broker QM. Now if they would just make the broker HTTP listener more robust I could get rid of the tc server........on and on....
Anyway the MQ and WMB portion of this works great just all those other "fixes" type of crap make it challenging
I dont see WAS7 making this much easier either unless I go back to client connection ? |
With WAS there is no reason to collocate MQ and WAS. WAS has the etc client and will do multiphase commit over a client connection 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| brianb |
| Posted: Wed Dec 15, 2010 12:51 pm Post subject: MQ MI WAS |
|
|
Voyager
Joined: 12 May 2010
Posts: 85
|
hi
Separate from MI discussion
I understand that WAS and MQ do not need to be on same box and that is how it is currenly MQ is remote to WAS. It makes more sense to me to have the Application and MQ on same box and use bindings...
Problem - too many client connection channels connecting to prod QM which in the past has caused the QM to stop accepting now connections.
Solution - was to put in a proxy QM to accept client connections
I am trying to get away from this design and putting the QM on the Application server that services it seems the way to go.
What does this give me ?
less complicated infrastructure
1. Faster
2 inherently secure no SSL required
3. No client channels
4. Connections to broker via server channels
5. Gets rid of proxy for client connections
Now back to MI
Suggestion to fail over WAS is interesting but ....WMB and MQ are tightly combined for MQv7 MI and fail over is built in.
In order to fail over WAS I think we are looking at a major chunck of work |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 15, 2010 1:53 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, again, the question is - what factors are there that would cause MQ and/or Broker to fail to the other box that would not also bring down WAS?
It doesn't necessarily have to be the SAME instance of WAS that actually moves between machines, it could just be that you configure a shell script to start a local WAS instance from an MQ Service. Then you just need to give the mqm user permissions to sudo to the was instance id.
You need to pay a bit more attention to deployment procedures in this case, however, as you need to ensure you deploy to both instances (which means starting one up in a non-functional state because MQ is not there).
On the side subject of Broker http server resiliency - in 7.0.0.1 at least you can get rid of biphttplistener entirely and do all of your HTTP traffic through the EG level SOAP listener.
You can then deploy the HTTP Proxy Servlet in your WAS instances, and get rid of your TC.
You can use the HTTPProxyServlet in 6.1 as well, but you still need to run a bipHTTPListener - so if that's the source of your feeling that it's unreliable, you don't gain much. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Dec 15, 2010 10:09 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
Another solution would be, to use the exit BlockIP2. This exit is able to limit the number of connections on channel level. In this case your problem
| Quote: |
| too many client connection channels connecting to prod QM which in the past has caused the QM to stop accepting now connections. |
would not occur.
In version 7 of MQ such a mechanism is built-in in WebSphere MQ as new channel attributes.
But if you do not have MQv7 and do not like exits you should consider - as mqjeff asked - to move WAS and WMQ together to another hardware in case of failure. In this case I would not use multi-instance QMrgs but a "normal" HA solution such as HACMP, Veritas etc. These soulutions would also take-over the IP address.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 16, 2010 1:13 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| WMQ v7 has client channel connection limits per channel and/or per IP address of client. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 17, 2010 8:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Problem - too many client connection channels connecting to prod QM which in the past has caused the QM to stop accepting now connections. |
Can you define too many?
For how many defined channels?
Are you sure that the applications running on WAS are well behaved and release properly the acquired connections?
We have a WAS farm that connects to 3 qmgrs and have seldom over 1,000 connections per box from WAS.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
