MQSeries.net :: View topic

royr · Posted: Tue Aug 21, 2001 6:34 am Post subject:

Hi,

"Why shouldn't I share the same local queue between processes that have different functions?"

During the design stages of an MQ application, a stubborn customer came up with this question and is unwilling to let go. I need hard answers (preferably references to official IBM documents or quotes from IBM employees) for it.

By "different functions" I don't necessarily mean a mix of message types in the same queue, but different processes, each doing a different (but similar) kind of work.

For example: Suppose I define a queue that contains debit requests from both credit card companies and bank transfers. Two processes serve the queue, one handles credit card companies requests and the other handles bank transfers. Each process knows exactly which messages should it get (say by selecting from the queue by CorrelId).

What's wrong with this design? It's technically feasible, and IBM does not recommend against it in any of the documents I saw.

I came up with some answers myself, but none of the seem to kill the argument:

1. Selection by CorrelId is expected to cause performance degradation.

2. One process can overflow the queue (e.g., if its messages are accumulating faster then they're processed), disrupting the other process.

3. One process backouting can disrupt the other process BROWSE_UNDER_CURSOR requests (HOW? I got a strong feeling it can happen, but can't explain).

4. Debugging a single process is hell, since the queue is stuffed with irrelevant messages.

5. Because I said so.

One irrelevant answer is:
Multiple servers on the same queue cause performance degredation because of the sharing overhead. It's actually usually recommended to run several instances of the same process serving the same queue to improve performance.

Can you help guide this lost sheep to its herd?