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?
This topic has been locked.
5 replies Latest Post - 2013-01-14T06:10:58Z by dplearner137
Pinned topic MQ Health Check
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-14T06:10:58Z at 2013-01-14T06:10:58Z by dplearner137
samanderson 2700034TEY172 Posts
swlinn 100000E7QE1344 PostsACCEPTED ANSWER
Re: MQ Health Check2013-01-09T14:56:45Z in response to dplearner137The 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:10Z in response to dplearner137Thanks 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 100000E7QE1344 PostsACCEPTED ANSWER
Re: MQ Health Check2013-01-09T19:30:51Z in response to dplearner137So let me address your latter comment first. The only times I've seen DataPower reload with MQ was due to the queue manager configuration which caused the message(s) to be retried over and over again. Do you have units of work configured with a nominal (1) retry threshold? You can also set var://service/error-ignore = 1 so if your backside put fails, the message is simply discarded and no retry is attempted. If the above advice doesn't help, if you have situations where mq connectivity is causing a reload, open a PMR and support will figure out what is causing this with your configuration.
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.