B
Bill Wood
Guest
WRT I just need a simple solution for a rest service. The ‘problem’ is that the REST client requirements are at some level in opposition to the JMS specification. The Queue is designed to separate one or more receivers on the queue from the mechanics of the client. Though it may seem clear that the messages are all for one REST client, JMS puts architectural restrictions on the ability of a client to ‘KNOW’ what is waiting for it. Changing the PREFETCH (and the PREFETCH THRESHOLD) are the only way to approach what you want, but this is not a guarantee that the queue will be cleared. (Past discussions on this thread have talked about PREFETCH, but you do need to set the prefetchThreshold to 1 otherwise you will find you get 1 message on every 2 nd request (approximately). The basic problem is that in JMS the specification does not allow/specify a way to ‘clear a queue of pending messages’ on a single call. In SonicMQ it is even more complex when you consider what is involved when you have a cluster of brokers, or a network of Routing Nodes. In these cases the messaging servers don’t even have a view of “what is every message that should go to a particular client”. Messages for a single queue might be distributed across different brokers, for example. From a REST client (or rather an HTTP Client) you can configure a direct connection to the SonicMQ broker to get the next message. That will only be one message at a time, but should relieve you from having to go through the AppServer (if that is an issue). Others may have a suggestion, but the only think you might otherwise do is have the appserver continuously move messages from Sonic into a Database table. Then when a REST client wants something, you would query the messages in the table and bundle them up into a single REST response.
Continue reading...
Continue reading...