Hello,
we try to upgrade from the MQ Adapter 2.1 to 6.0 and we run into a lot of problems (as it is a major change).
Has anyone already experience?
So far we have been successful in getting Listeners up and running. But we currently stuggle with getting the message rolled back to WebSphere MQ if the flow service will fail (in the passed we received the message from the queue and processed them. If there was a problem it was rolled back to the queue and we stopped the listener).
The documentation for 6.0 tells me to use a synchronous listener notification (asynchronous will removed the message from the queue when the notificaiton will be called) but I’m unable to create one. The developer is not showing any error message. It just remains at the Adapter Service Name window.
Any help would be appreciated.
Thank you
Did you solve this issue?
We just experiencing similar problem using MQ Adapter 3.1.
If message retrieved from MQ by get method and just after that Integration Server shuts down (we have overall webMethods stability problem)the message is not rolled back on MQ. Queue is persistent and we expect the message to stay on MQ
We have been using MQ Adapter 6.0 successfully…since one year…we did not face any major issues.We have upgraded it from V3.1 to V 6.0
We have been using tranactional connections.In this case it takes care of the rollback situation,if the message is not processed successfully…
HTH
Uday
We upgraded from 3.0 to 6.0. Make sure you go to 6.0 SP1 now though.
In the 3.0 version and 6.0 version there is an issue with getting messages off of the queue (or something to do with the retrieval of messages). In order to get it to work properly you have to use overrideReplyToConnection. We had a SR open that was resolved with a fix that is bundled into SP1.
However, when you go to 6.0 SP1 make SURE you take out the overrideReplyToConnection variable if you are using it. When using this variable, the ART does NOT use the settings you specify in the Admin UI. So, you will not be using your maximum connections, timeouts, minimum connections you specified in Admin UI. You won’t have ANY of thes settings at all unless you specifically set them in overrideReplyToConnection.
6.0 SP1 seems to be pretty stable though.
Afraid I can’t talk about transactionality for MQ.
We used it pre-SP-1 and ran into a major issue when doing an ansynchronous get and trying to publish to broker when the broker wasn’t available it defaulted to the MQ SYSTEM.DEAD.LETTER.QUEUE (in addition it wrote the DLH (dead letter header) onto the message). When our DLQ filled up, and then held transactions in (I believe) the outbound doc store until it could process, but unfortunantly the message still had the DLH in the datagram and thus when publishing resumed it published mal-form data to the Broker. The subscribers to the Broker data then “blew up” when they received teh mal-form data.
We got wM to fix this and it’s rolled-up in SP-1.
Roy
Roy,
We have faced a similar type of issue.Instead of pointing to the dead letter queue,we pointed to the originating queue.Then we did a “get” again…it does not consider the the dead letter header at that point of time…
Thanks
Uday
We have an issue with dead letter headers being added to mq records as they come it. We have SP1 installed. It is happening on one server (distributed environment) where we have had troubles with the broker (works on other server within that environment). We did have an issue with wM writing MQ records to the dead letter Queue but that was resolved with a fix from wM some time ago. Any ideas?