The multiple queues is for routing and concurrency purposes.
There are no transactional concerns. We are using WMQ for synchronous messaging.
The software is live now so redesigning isn't really an option. The problem has only started occurring recently. The operations team would stop and restart MQ on a nightly basis and at the weekend the box is IPL'd. On Monday the problem did not occur which makes me wonder if its something to do with the MQ restart process.
I believe the flaw is essentially in the design. Remember WMQ is inherently asynchronous and not synchronous, so any operations that are real time look quasi synchronous.
This being said you will at some time close a session / connection holding a msg and having a trigger message on the INIT queue. At which point you will get the error. (queue does not exist).
You state that the purpose for the multiple queues is for routing and concurrency... again wrong design.
Most routing (return path) information needs to be in the message (MQMD) and any forward processing routing should be either in the destination queue or in the message. So if you are triggering the same application from multiple queues, especially dynamic queues, your design might not follow best practices.
As for concurrency: writing a thread-safe processing application and running multiple instances of it, should take care of that aspect...
I understand it makes writing the app more complicated, especially if you trigger every and have to limit the number of instances dynamically (and are not using the MF resource manager to do so)....
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum