Please report new issues athttps://github.com/DOCGroup
This is just list of features that should/will be implemented for TAO's next generation load balancer, slated for release in TAO 1.2. Most of this stuff is already described in the load balancing paper Doug, Carlos and myself wrote. The URL for the paper is listed above. - implement new interface based on the FT service IDL - the beginnings of this are already in a CVS branch - take advantage of portable interceptors to make it possible to implement transparent load balancing on the server-side. - improved load balancing strategies/algorithms - the strategies provided with TAO should be able to make load balancing decisions based on multiple load metrics. This requires that it is possible to send multiple loads in single load report, e.g. by using the following IDL: module LoadBalancer { typedef unsigned long LoadId; struct Load { LoadId identifier; float value; }; typedef sequence<Load> LoadList; }; - implement a load monitor that uses the CPU load as the load metric (e.g. obtain load information from /proc filesystem on linux platforms) - state migration (lower priority than other features) - provide for different load monitoring granularities and hierarchical load monitoring. - rather than always redirecting client requests back to the load balancer, look into the possibility of forwarding requests directly to another replica, thus saving us an additional forward. - Add a new load state that would control whether or not the load monitor would throw a CORBA::NO_RESOURCES or CORBA::TRANSIENT exception (whichever is appropriate). For example, in addition to the high/low load advisories, the load balancer could issue a "no resources" advisory which would cause the load monitor to throw the appropriate exception.
Another wishlist item: decentralized load balancing
Mine.
The ClientRequestInfo::target() issue may be a blocker for the new load balancer's load shedding functionality.
Most of these items have been implemented. All that is left is the following: > provide for different load monitoring granularities and hierarchical load > monitoring. It somewhat possible to do this with the new load balancer. However, it is currently up to the user to set up load monitors hierarchically. > rather than always redirecting client requests back to the load balancer, look > into the possibility of forwarding requests directly to another replica, thus > saving us an additional forward. This functionality will not be implemented. The additional complexity outweighs the benefits, if any. > Add a new load state that would control whether or not the load monitor would > throw a CORBA::NO_RESOURCES or CORBA::TRANSIENT exception (whichever is > appropriate). For example, in addition to the high/low load advisories, the > load balancer could issue a "no resources" advisory which would cause the load > monitor to throw the appropriate exception. In the new model, the load monitor is no longer responsible for load shedding. It's sole purpose is now to monitor loads. A "LoadAlert" entity has been added that deals with load shedding. It this LoadAlert object that should be responsible for the above functionality.