I'm well, thanks for asking!
Regarding /Q interoperability, I'm not sure exactly what you are trying to accomplish. If this is really across domains, then there shouldn't be a problem. /Q uses the TMQUEUE servers to provide access to the /Q queues. Those TMQUEUE servers are accessed via a service name that is the same as the /Q queue name. The tpenqueue() and tpdequeue() API's simply call a service by the name of the queue space underneath the covers. So you can support /Q across domains by importing the queue space name as a service name in the domain gateway configuration. Since we support domain connections across Tuxedo versions, this "should" work, meaning, you or the customer should test this first. Make sense?
As far as queues per queue space, I think this is largely a scalability question. Each queue space has one or more TMQUEUE servers that manages the queue space including all queues in it. So if you have a single queue space with 5 queues in it and a single TMQUEUE server, then you can handle at most 1 concurrent /Q operations to those queues. Had you defined those 5 queues each in a separate queue space, then each one would have its own TMQUEUE server meaning you could service 5 queue/dequeue requests simultaneously.
I hope that helps!
For now, we want to accomplish oracle tuxedo's features tests so we can better come to right decisions on our major problems and architectural decisions as they are going to require. In fact, it is cross domain configuration I was talking about. Sorry for not having mentioned it.
Also, we have been diving into tuxedo so we can deliver better solutions and services on it.
I hope I am not being annoying for you.
Thank you for answering my questions you got the point I have asked you.
Bye. See you tomorrow. Todd Little-Oracle
Taking opportunity we discussed queue scalability, how about keeping one queue space per queue device file? are there advantages keeping one queue device file for each queue space? if so. briefly, what are the main pros and cons?
Also, Thank you for having answered my questions until now Todd Little-Oracle
This largely depends upon whether you are doing using persistent messages or transient messages. For transient messages it doesn't really matter as the queue space file really just hold the queue space parameters and not the actual messages, so the file is used only very infrequently. For persistent messaging however, every persistent message queued causes a synchronous write to the queue space. So the question of scalability becomes one of the underlying file system. If for your particular platform/configuration you can get more file system throughput by accessing multiple files instead of a single file, then having a separate queue space per queue makes sense. However if your platform/configuration makes the separation of requests to different files immaterial with respect to performance, then it doesn't really matter. Let me see if I can give some examples:
Let's say your queue space is on a single SAS 7,200 RPM drive. That would yield about 75-100 IOPs so your enqueue/dequeue rate is going to be below that. Not very good. If you move to 15K drives, expect about 200 IOPs. To really improve things you need to switch to either RAID configurations (say RAID 5), or SSDs possibly also in a RAID array. A RAID 5 array requiring 1000 IOPs will need enough drives to provide 2,500 IOPs at a 50/50 read/write ratio. That will take ~25 7,200 RPM drives, or around 12 15K drives. If you switch to SSDs, then the number of drives becomes significantly less. Current SSDs provide 100,000 to over 1,000,000 IOPs, which makes IOP performance almost irrelevant. :-)
In any case, the issue is really IOP rate, so however your file system/hard drive subsystem is configured will determine the value of splitting queues across multiple queue spaces or single queue spaces. However, one thing to keep in mind is that queues sharing a queue space also share a shared memory section that requires coordination, i.e., locking. So having all your queues in a single queue space can increase the contention on the queue space, whereas having each queue in its own queue space reduces contention at the expense of more queue spaces to worry about and more TMQUEUE servers to have configured. There are no real hard and set rules around what is best for all situations.
Oracle Tuxedo Chief Architect
I just realized that I didn't completely answer your question regarding multiple queue spaces in a single queue device file. Personally I don't see any advantage to doing that. The whole notion of the Tuxedo file system came about I believe partially to better support raw devices early on that had better performance than the Unix file system. With today's modern file systems and kernels, I don't see any particular value to placing multiple things in a Tuxedo device file.
Oracle Tuxedo Chief Architect