MQSeries.net :: View topic - Discourse \ MQ Dyanmic Queues vs Predefined Queues

hopsala · Posted: Sun Aug 21, 2005 7:07 am Post subject:

(Yes, I know this has been discussed many times in the past, but the world and industry changed since, and possibly I may still have some new ideas to pass. So here goes:)

I'm somewhat old-fashioned in my perception of MQ - I like to have complete control over what's going on; dynamic queues are, since they are automatically created and managed, pretty much out of the admin's hands.

For example, if an application opens a PERMDYN queue, forgets to close it and goes on doing whatever it is it was doing, the queue is "stuck" - the admin has no idea whether it is in use or not; the only way to know is to start going through appl logs of all clients, which are usually either unavailable or problematic to access (say, in large number of clients).
Plus there's the security issue, you cannot give specific access to specific temp queues, because you do not know their name in advance. the only way to solve this is give permissions to the modelq, and open a q called BIGAPPL.SMALLAPPL.* where BIGAPPL is the name of the entire structure and SMALLAPPL is the name of that specific client; then you give permissions to each and every dyanamicq in advance, before it is created.
Thing is, this entirely misses out on one of the main points of dynamic queues - they should be used when you do not know in advance who your clients are, and how many are there. Also, in every possible scenario, you'll have to give permissions to the queue of the receiving appl.

Even in such cases, in which you don't know who your clients are, usually I won't use dynamic queues. The client appls have to know in advance the name of the modelq anyway, so there's no difference between that or knowing a name of a q for all clients.
And as for many appls using one queue, why not? use corrlid/msgid and index queue by it. I know there are "performance issues" but usually the machines nowadays can take it - it is "wasteful", but if it works so what?

But then you'll say (justly) that there are performance issues. Say you have 500-1000 clients going about putting 1MB msgs per minute each, to such a scenario there's another interesting solution - using a small handshake with the receiving application to determine which q to open.
You create about 1000 qs in advance (max clients to connect) and have the receiving appl answer a new client which queue to open (and even give them permission only on bind!). This gives you better control and a solid log of what's going on, which is a definite plus - though indeed requires some code.

In summary, I think dynamic queues should only be used for dynamic scenarios - unknown clients - but that MQ for such scenarios is simply not a very good solution; It is much easier, and more administratable, to implement pub/sub solutions in webservices or other synchronous protocols, due to what I stated and much more (i've already written too much).
In cases which you have to use mq for pub/sub, I would go with queues created by the receiving application, and would use mqclients. This give the receiving appl absolute control over subscription queues, and permits such things as deleting publications if needed.

In final summary, I don't believe in MQ for client-end solutions at all, and all this is one of the reasons why. Clients should be HTTP, like every new project is nowadays, only the backend - the skeleton - of the network should be MQ.

Well, got a little carried away there didn't I? Sorry. In any event, this is my general opinion of the subject, but I would appreciate feedback