Has anyone implemented or know of a resolution for the capability of webMethods processing MQSeries messages in FIFO order and also provide the ability to process a high volume of messages?
We need the ability to process 15,000 messages per minute while maintaining FIFO order of those messages as they were written to the MQ queue we’re listening on. We also need to provide guaranteed messaging for these messages so that no messages are lost if the distributed SQL side we’re writing them to is not available (like in cases of system failures).
Is this possible within webMethods and if so, what is the recommended solution that provides all of the above?
Diane,
I’m not sure you are going to get a 250 m/psec throughput on a single thread which would normally be the solution for a serial trigger that needs to keep the message order.
I’m curious about requirement for a FIFO solution for such a large message volume and you also wanted rollback capabilities as well? There may be some more robust alternatives that if you want to share more details of the requirements/project goals.
Also can you tell is your IS going to be in a cluster environment?
If you want it to be FIFO sounds it has to be in a serial mode on the trigger which can affect the performance level in processing the heavy volume of messages. Does concurrent cannot be a solution for you in this case?
Sorry for not replying sooner, we were able to finally get the applications to make use of a timestamp field in the data to remove the FIFO requirement so that we can set the JMS triggers to concurrent. We do have a clustered environment that the JMS triggers will run in so are testing with the various settings on the triggers for performance beings we will have multiple triggers and need to be careful we don’t overload the IS threads, etc.
Diane,
As you have clustered environment, you will have to use Async notification mechanism which will send the message through Broker (native/JMS). Sync invokes the service directly and it doesn’t support cluster…
In order to read the messages faster from MQ, the service invoked by trigger need not do entire logic or write to db, rather publish to broker again (map to some canonical) which will free the resource held by trigger1. The trigger2 can be concurrent, with possible max batch size set to >1 and do remaining logic…