TMQUEUE advertises a service which by default is the name of the queuespace, not the queue. As well, when tpenqueue() and tpdequeue() perform their work, they make requests to a service with the name of the queuespace. As Tuxedo doesn't know these service names are associated with a queue space, it will load balance requests to multiple TMQUEUE servers that advertise the same queuespace name. In fact, for scalability purposes you can configure multiple TMQUEUE servers operating on the same queuespace provided they are on the same machine as they will share the shared memory section associated with the queuespace. If this is done on different machines, the queuespaces need to be different, even though they have the same name. The access to the specific queues will be undefined, meaning that if you enqueue msg A and then try to specifically dequeue msg A, you may get an error because msg A may have gone to one queuespace, and the dequeue request went to the other.
We are working on enhancements to Tuxedo Message Queue (an enhanced message queuing offering for Tuxedo) to make something like this work in a more transparent manner, i.e., the dequeue for msg A would work regardless of which machine/TMQUEUE server handled the request.
Oracle Tuxedo Chief Architect
Hey Todd, thanks again for the replies, you've been a lifesaver!
So, as far as I understood, there`s no way for me to safely run a tpdequeue on a multiple machine queuespace using Load balance configurations? The only way would be to keep the Queuespace in a single machine?
Regarding the Tuxedo Message Queue enhancement you talked about, does it have a planned release date? It would prove very useful for us, especially in a situation of a clustered Tuxedo envrionment.
Thanks very much,
It all depends upon what "safely" means. :-) In all seriousness, can you describe what it is you'd like to see? You can have multiple queuespaces with the same name (and preferably with the same queue names!) and it "should" work within certain constraints. If you have multiple processes performing tpdequeue() operations on multiple machines and you've set NETLOAD adequately, it will probably work just fine, especially if there is a regular flow of messages. However under extremely low loads, it is conceivable that multiple servers may be trying to perform tpdequeue() operations, and all of them stall, even though there is a message.
I think there are some ways to solve this problem using client server affinity, although it would have to be tested to verify that. Basically the idea is you create a dummy service on each machine, the local enqueuers and dequeuers call this service and it is set to establish a client/server affinity context with the machine. From then on subsequent requests should be part of the affinity context and try to go to the local machine first. Only if the local machine cannot handle the request would the request go to the other machine. This would then ensure that as long as there are multiple dequeuers on each machine, they would end up going to the local TMQUEUE servers. As I say, in theory this should work, but it would be worthwhile to test.
I'm not sure what the release schedule is for the version of TMQ that will support transparent clustering, but I can try to get that information to you. Can you please send me an email and I'll send you what I have? My email address is simply my first name period last name at oracle.com.
Oracle Tuxedo Chief Architect
Thanks for the reply. I also agree that, in theory, the client server affinity should work.
I will make some further tests trying to work with this and will let you know if I find something relevant.
Regarding the TMQ, I will send you an email shortly.