Throttling MDB performance running against MQSeries queue

Question

I have an unusual requirement for an application. We have a non-transactional MQSeries queue that is bound as a foreign JMS destination in client mode (thanks to the folks on the forum who helped me configure that!).
          The problem is that the cluster that we are running our application on has limited capacity and I need to make sure that the MDB that will be listening to the queue does not surpass a certain TPS limit (say, 1 TPS). This article explains how to throttle performance using a separate execute thread -- http://e-docs.bea.com/wls/docs81/perform/AppTuning.html#1105201
          However, this requires you to set the MDB's "dispatch-policy' attribute to the lower priority queue in ejb-jar.xml. However, the documentation on this attribute -- http://edocs.beasys.com/wls/docs81/ejb/DDreference-ejb-jar.html#1113605 -- indicates that this attribute is only honoured if the source queue is transactional in nature.
          What to do? A transactional queue is a hard sell to our infrastructure folks. Can I use the extended transactional client and have this work?
          FYI - using the max-beans-in-free-pool does not do a sufficiently good job of limiting performance.
          Any other ideas?

Answer 1

another possibility might be the following scenario:
          create a local jms-destination, maybe with a jdbc-store.
          then use the weblogic bridge to transfer messages into the local jms-queue.
          at this point you can configure flow-control for the connection factory
          to limit transferred messages.
          the problem in this case is, that unprocessed messages have to be stored
          on the application server or in the database.
          but maybe this can help you.
          --Klaas
          gbrail schrieb:
          > As the doc describes, your MDB's "onMessage" method is invoked by a thread created by MQ. That means we have no control over it, or how fast it runs. I don't know of any "throttling" features in MQ either that would help.
          >
          > The only (ugly!) suggestion I can think of is that you should set "max-beans-in-free-pool" to 1 and periodically "sleep" in your onMessage method so that you don't get messages too fast!
          >
          > (And even if you were able to use a separate execute queue, or a transactional queue, you still could potentially get messages more than once per second, so you might still need to sleep anyway.)