What are the available options in Datapower to do MQ health check.
We would like to have a mechanism in place where datapower would stop making MQ calls when the MQ system is down and discard these transactions.
Is there a way we can do tcp connection inside the datapower flow for MQ?
samanderson 2700034TEY172 Posts
Re: MQ Health Check2013-01-09T13:01:29ZThis is the accepted answer. This is the accepted answer.Datapower is state less so your
We would like to have a mechanism in place where datapower would stop making MQ calls when the MQ system is down and discard these transactions. is not possible
swlinn 100000E7QE1348 Posts
Re: MQ Health Check2013-01-09T14:56:45ZThis is the accepted answer. This is the accepted answer.The appliance does provide a queue manager group for failover purposes. If your desired QM is down, then the put will be done to a failover QM. Another approach if your MQ infrastructure is more complex would be to do the put against a queue manager group, but the request queue would be a clustered queue which may not be local to either of the QMs that DataPower connects to. MQ will route the request and will work load manage between the instances of the clustered queue, so if one of those QMs is down or put disabled, the put will go to another instance.
Re: MQ Health Check2013-01-09T15:56:10ZThis is the accepted answer. This is the accepted answer.Thanks Steve for your inputs.
Considering we use application queue manager group configuration and if we run into a situation where we have both the primary and secondary QM's to be down then datapower still keeps writing to the MQ port due to the incoming transactions.
We want to put a mechanism where Datapower would automatically disable writing any transactions to MQ when both primary and secondary QM are down.Once MQ is back it should again automatically start writing transactions into it.
We had seen situations where Datapower would reload due to MQ connectivity issues and we want to avoid these situations.
swlinn 100000E7QE1348 Posts
Re: MQ Health Check2013-01-09T19:30:51ZThis is the accepted answer. This is the accepted answer.
- dplearner137 270005EF4T
After consulting with one of my compatriots, the only thing that we thought could work would be to use a dynamic mq url (mq:// urla, NOT dpmq:// url). In these urls, you specify your host name of your MQ server (any anything else you're used to in the queue manager config) in the mq url itself, and the hostname parameter could be a load balancer group object name. The health checks configured on that LBG should be "LDAP", yes, I don't like the name either, but effectively, this is a TCP health check just to see if the IP:Port is has a listener. If successful, the member will stay up, if fails, will be taken down. The negative may be some performance impact, as statically defined Queue Manager (or QMG) objects will perform better and may have connections already open that can be utilized, but I have not used mq:// urls to have an idea of how much to quantify any performance concern. One other caveat ... I believe the LDAP health check type uses the health port on the health page, ignoring the health port on the members page, so if you have MQ instances on different ports of the same server, for example, 1414 and 1415, the health check will be sent to the one instance twice, which will not notice the other has gone down. I believe there is a request for enhancement to change that, but no idea where in the product pipeline that is.
My recommendation would be to solve the root cause of your reloads, which I'd suspect could be solved with your queue manager configuration, but otherwise, you can try and test the dynamic mq url approach.