CLB Meeting Minutes for August 31st

Following are the points

1. CLB Initialization

• This would be implemented as part of SIPServiceListener. A new layer class, provided to dispatcher.xml, would provide a layer interface implementation and composition for HTTP CLB object.
• dispatcher.xml will be the nodal point for CLB initialization to be initiated. The new class would check for the presence of the converged-loadbalancer element in domain.xml for further initialization to proceed. Thus we have the
  CLB always coded in dispatcher.xml; however the presence/absence of the "converged-loadbalancer" element in domain.xml would decide whether or not CL:B is registered with Web/SIP stack as Valve/Layer respectively.
• The above would require the glue code / supporting code for dispatcher.xml to be re-factored a bit; given that it would only require only SIP layer interceptor - Layer to be registered and the Valve implementation would be self registered as part of sourcing the start-up events.

2. A requirement on the GlassFish container implementation to provide for an API, which when used iteratively upon server start up would result in Valves to be registered as "Basic/front-end" and thereby defining the order in which the pipeline Valves are to be executed. All Valves that need to be executed as part of requests local termination should be registered by the server/container towards the end of the pipeline.

3. The existing EAS code would require some re-factoring to use the support mentioned in point 2.

4. The CLB admin runtime would cause initialization of CLB core runtime objects for both HTTP and SIP.

5. There would exist only one RequestGroup called "DefaultGroup" for SIP CLB core runtime. The request handler would maintain mapping of a request group name to RequestGroup.

6. RequestGroup would be extended to SIPRequestGroup to support APIs specific to SIP request processing.

regards
Pankaj