Re: Jetty 6- Clustering - How it works
Hi, Sorry to get back to you only now. I have captured the details of how to set-up a demo system there: http://cwiki.apache.org/confluence/display/GMOxDEV/Clustering +Configuration+for+Jetty I am putting the implementation of an integration test on hold as I would like to start working on the online deployer and the registration of module configurers as I promised in another thread. Thanks, Gianny On 07/01/2007, at 2:47 PM, David Jencks wrote: Wow this is great!! Are there instructions somewhere on how to set up a demo system? Having an integration test would be even better :-) thanks david jencks On Jan 6, 2007, at 7:30 PM, Gianny Damour wrote: Hi, I think that support for clustered Web-applications with Jetty is now working.
Re: Jetty 6- Clustering - How it works
really awesome work Gianny, I know you've worked very hard on it. Filip David Jencks wrote: Wow this is great!! Are there instructions somewhere on how to set up a demo system? Having an integration test would be even better :-) thanks david jencks On Jan 6, 2007, at 7:30 PM, Gianny Damour wrote: Hi, I think that support for clustered Web-applications with Jetty is now working. Here is a description of how this works; note that most of the described behavior is WADI specific. Group Communication Group communications are performed by Tribes, which is the Tomcat 6 group communication engine. I know very little of Tribes; however, I am pretty sure that Filip Hanik can give us an in-depth description, if requested. At a very high level, Tribes provides membership discovery and failure detection. It also provides basic message exchange communication primitives, that WADI builds upon to provide additional message exchange operations (e.g. request-reply). Logical group communication engines are layered on top of the above (physical) group communication engine. A logical group communication engine, a ServiceSpace in the WADI's terminology, provides the same features than a physical group communication engine and allows the definition of sub-groups. This means that at the physical level, you could have three nodes interconnected and at the logical level only two of them could appear as existing. Clustered Web-Application Discovery A clustered Web-application is placed into a logical group communication engine, which is uniquely identified by a URI. This URI is the Artifact id of the Web-application configuration. When this Web-application starts, the logical group communication engine starts and joins the logical sub-group identified by its unique id. Conversely, when the application stops, the logical group communication engine leaves the logical sub-group. Partitioned State WADI implements a partitioned session state topology. In a cluster all the session states are distributed across the cluster nodes and only one node holds the state of a given session. This design choice was made to improve scalability with respect to the size of data to be managed by a single node. Session locations, information required when a node requests a session that it does not hold, are also managed by a single node. When a node fails, the session states and session locations managed by this node are lost and WADI is able to recreate them. Session states are lazily recreated from replicas. Session locations are recreated by querying the cluster and asking each member what are the sessions that they are currently holding. Session Creation When an inbound request wants to create a new HttpSession, a WADI session is created. This session is hosted by the node receiving the inbound request. An HttpSession using under the cover the WADI session is then created and returned. Under the cover, WADI ensures that the session has a unique identifier cluster-wide. Session Migration When an inbound request wants to access an HttpSession and this session is not hosted by the node, The node hosting the requested session migrates it to the node receiving the request. Under the cover, WADI ensures correct handling of concurrent session migration requests via a locking approach and maintains its internal book keeping of session locations following migration events. Session Replication When a request complete, the WADI session used under the cover of the HttpSession is notified. The WADI session is then replicated synchronously to one or multiple nodes. The selection of the back-up nodes for each session is customizable via a plugin strategy. When a node fails, replicas are re-organized based on the new list of existing members. Fail-Over When an inbound request wants to access an HttpSession, which was hosted by a node which has died, the cluster is queried for a replica of the requested session and an HttpSession is recreated if possible. Session Evacuation When a Web-application stops, all the session that it holds are evacuated to the other nodes hosting the same clustered Web-application. It will take me 1 to 2 weeks to test specific error scenarios and ensure correctness; meanwhile, if anyone wants to know more of some specific areas, then please feel free to ask. Thanks, Gianny --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date: 1/5/2007 11:11 AM
Jetty 6- Clustering - How it works
Hi, I think that support for clustered Web-applications with Jetty is now working. Here is a description of how this works; note that most of the described behavior is WADI specific. Group Communication Group communications are performed by Tribes, which is the Tomcat 6 group communication engine. I know very little of Tribes; however, I am pretty sure that Filip Hanik can give us an in-depth description, if requested. At a very high level, Tribes provides membership discovery and failure detection. It also provides basic message exchange communication primitives, that WADI builds upon to provide additional message exchange operations (e.g. request-reply). Logical group communication engines are layered on top of the above (physical) group communication engine. A logical group communication engine, a ServiceSpace in the WADI's terminology, provides the same features than a physical group communication engine and allows the definition of sub-groups. This means that at the physical level, you could have three nodes interconnected and at the logical level only two of them could appear as existing. Clustered Web-Application Discovery A clustered Web-application is placed into a logical group communication engine, which is uniquely identified by a URI. This URI is the Artifact id of the Web-application configuration. When this Web-application starts, the logical group communication engine starts and joins the logical sub-group identified by its unique id. Conversely, when the application stops, the logical group communication engine leaves the logical sub-group. Partitioned State WADI implements a partitioned session state topology. In a cluster all the session states are distributed across the cluster nodes and only one node holds the state of a given session. This design choice was made to improve scalability with respect to the size of data to be managed by a single node. Session locations, information required when a node requests a session that it does not hold, are also managed by a single node. When a node fails, the session states and session locations managed by this node are lost and WADI is able to recreate them. Session states are lazily recreated from replicas. Session locations are recreated by querying the cluster and asking each member what are the sessions that they are currently holding. Session Creation When an inbound request wants to create a new HttpSession, a WADI session is created. This session is hosted by the node receiving the inbound request. An HttpSession using under the cover the WADI session is then created and returned. Under the cover, WADI ensures that the session has a unique identifier cluster-wide. Session Migration When an inbound request wants to access an HttpSession and this session is not hosted by the node, The node hosting the requested session migrates it to the node receiving the request. Under the cover, WADI ensures correct handling of concurrent session migration requests via a locking approach and maintains its internal book keeping of session locations following migration events. Session Replication When a request complete, the WADI session used under the cover of the HttpSession is notified. The WADI session is then replicated synchronously to one or multiple nodes. The selection of the back-up nodes for each session is customizable via a plugin strategy. When a node fails, replicas are re-organized based on the new list of existing members. Fail-Over When an inbound request wants to access an HttpSession, which was hosted by a node which has died, the cluster is queried for a replica of the requested session and an HttpSession is recreated if possible. Session Evacuation When a Web-application stops, all the session that it holds are evacuated to the other nodes hosting the same clustered Web-application. It will take me 1 to 2 weeks to test specific error scenarios and ensure correctness; meanwhile, if anyone wants to know more of some specific areas, then please feel free to ask. Thanks, Gianny
Re: Jetty 6- Clustering - How it works
Wow this is great!! Are there instructions somewhere on how to set up a demo system? Having an integration test would be even better :-) thanks david jencks On Jan 6, 2007, at 7:30 PM, Gianny Damour wrote: Hi, I think that support for clustered Web-applications with Jetty is now working. Here is a description of how this works; note that most of the described behavior is WADI specific. Group Communication Group communications are performed by Tribes, which is the Tomcat 6 group communication engine. I know very little of Tribes; however, I am pretty sure that Filip Hanik can give us an in-depth description, if requested. At a very high level, Tribes provides membership discovery and failure detection. It also provides basic message exchange communication primitives, that WADI builds upon to provide additional message exchange operations (e.g. request-reply). Logical group communication engines are layered on top of the above (physical) group communication engine. A logical group communication engine, a ServiceSpace in the WADI's terminology, provides the same features than a physical group communication engine and allows the definition of sub-groups. This means that at the physical level, you could have three nodes interconnected and at the logical level only two of them could appear as existing. Clustered Web-Application Discovery A clustered Web-application is placed into a logical group communication engine, which is uniquely identified by a URI. This URI is the Artifact id of the Web-application configuration. When this Web-application starts, the logical group communication engine starts and joins the logical sub-group identified by its unique id. Conversely, when the application stops, the logical group communication engine leaves the logical sub-group. Partitioned State WADI implements a partitioned session state topology. In a cluster all the session states are distributed across the cluster nodes and only one node holds the state of a given session. This design choice was made to improve scalability with respect to the size of data to be managed by a single node. Session locations, information required when a node requests a session that it does not hold, are also managed by a single node. When a node fails, the session states and session locations managed by this node are lost and WADI is able to recreate them. Session states are lazily recreated from replicas. Session locations are recreated by querying the cluster and asking each member what are the sessions that they are currently holding. Session Creation When an inbound request wants to create a new HttpSession, a WADI session is created. This session is hosted by the node receiving the inbound request. An HttpSession using under the cover the WADI session is then created and returned. Under the cover, WADI ensures that the session has a unique identifier cluster-wide. Session Migration When an inbound request wants to access an HttpSession and this session is not hosted by the node, The node hosting the requested session migrates it to the node receiving the request. Under the cover, WADI ensures correct handling of concurrent session migration requests via a locking approach and maintains its internal book keeping of session locations following migration events. Session Replication When a request complete, the WADI session used under the cover of the HttpSession is notified. The WADI session is then replicated synchronously to one or multiple nodes. The selection of the back- up nodes for each session is customizable via a plugin strategy. When a node fails, replicas are re-organized based on the new list of existing members. Fail-Over When an inbound request wants to access an HttpSession, which was hosted by a node which has died, the cluster is queried for a replica of the requested session and an HttpSession is recreated if possible. Session Evacuation When a Web-application stops, all the session that it holds are evacuated to the other nodes hosting the same clustered Web- application. It will take me 1 to 2 weeks to test specific error scenarios and ensure correctness; meanwhile, if anyone wants to know more of some specific areas, then please feel free to ask. Thanks, Gianny
