This content has been marked as final. Show 6 replies
This is one restriction which i mentioned. Other one is that, to handle some exception condition there is provision to un-adverstise the service "OutFixEn".
This is the reasone why servers can not be put in MSSQ set. Case when these two servers put in MSSQ set and is one server instance we get an exception, service is un-adverstise and due to MSSQ set it becomes unavailable through second instance even.
This is the main limitation due to which i can not think for MSSQ set.
Edited by: AjeetTewari on 28 Jan, 2013 9:08 AM
The service which is unadvertise is only OutFixEn. It is there in both instances. If we create MSSQ to achieve load balancing then when this service is unadvertised then it is not avaialble from any instances.
When MSSQ is not there, if one of instances unadvertise then atleast service is available from another.
Question is, Is there a way to load balance services among two instances without using MSSQ.
maybe create a wrapper server in MSSQ. your two old servers will be on their own queues with different servicenames. server1
will have Foo1, Shmoo1, Bar1 and server2 Foo2, Shmoo2, Bar2. wrapper will make his own balancing calling services in round
robin fashion. if you would like to disable Shmoo2 service you will then keep it in server2 but instead of processing the message
you will respond "try the other one" and wrapper will call Shmoo1 (wrapper knows all services):
client --- calls Foo ---> (2 instances of wrapper server) --- calls Foo1 ---> server1 (next time wrapper will use services from second instance)
client --- calls Shmoo ---> (2 instances of wrapper server) --- calls Shmoo2 ---> server2 and gets response "try the other one" and
wrapper continues and --- calls Shmoo1 ---> server1 because server2 currently disabled his Shmoo service
Well it seems there are several possibilities:
Instead of unadvertising a service, inactivate the server or have the server exit. The restriction that all servers in an MSSQ set offer all the same services has to do with how Tuxedo uses System V IPC queues. With MSSQ all the servers share a single request queue. If we allowed servers to have different services advertised in an MSSQ set, Tuxedo would have no way of ensuring the proper server dequeued the request from the common IPC queue. If you have the server exist or set itself to be inactive instead of unadvertising the service, that would still prevent the service from being called in that server (as well as all the other services in that server). But if that is a problem, you could separate out that service into its own server with its own MSSQ set.
Another option as mentioned is to have an intermediate server(s) that simply forwards the requests to uniquely named services. Thus if you are currently calling services A, B, and C, then have the servers that would have been in your MSSQ set advertise services A_id, B_id, and C_id, where id is something to make the service names unique to the particular server. Then have a server or set of servers using MSSQ that simply tpforward() requests in a round-robin fashion.
Use /Q and have the client tpenqueue() the request onto a non-persistent queue and tpdequeue() the reply from another queue. The servers would then be modified to use tpdequeue()/tpenqueue() instead of being a service.
I guess my fundamental questions though are:
1) Why do you need a level number of requests done? Tuxedo is doing load balancing, i.e., ensuring that servers all have the same load on them. The issue is that when no servers have load, Tuxedo always gives the requests to the first free server, which is usually the best choice as that server is likely to be in memory and cache.
2) Why are you unadvertising a service? I know you said some error condition, but how does that error condition get cleared up? Can the server simply exit or set itself to inactive as I suggested above?
Oracle Tuxedo Chief Architect