[ https://issues.jboss.org/browse/JBTM-1104?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1104: -------------------------------- Summary: Does XTS support load-balanced scenarios? (was: Does XTS support load-ballanced scenarios?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-1104?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1104: -------------------------------- Description: Enabling session affinity on the load balancer should ensure that all requests for a particular application endpoint, within a particular session, go to the same instance of the web service. However, XTS advertises a number of endpoint addresses that will not make sense in a load balanced cluster. This is because it would be the internal endpoint address of the particular server that is advertised, rather than the load balancer's external address. Even if we configured XTS (not yet possible) to offer the address of the LB, we would still have a problem as XTS will use a different session to the application to send protocol messages and thus they will go to a different server that is not aware of this transaction. h4. Potential Solution For each web service that is deployed by XTS, we advertises a modified version of the load balancer's address. The modification to the url provides a unique identifier for the particular node in the cluster. The load balancer would then be configured to route messages based on the modification in the url. The LB would also re-write the URL to match that expected by the particular server that receives the message. This should be configurable per group of services provided by XTS (Client, Coordinator, Participant) as not all of these will, necessarily, be exposed via the LB. Each Service offered by XTS is deployed via JBossWS. XTS also maintains metadata about the endpoint which it advertises to other participants in the protocol. This metadata is currently kept in sync with the service, but it doesn't have to be. In this situation, the metadata could be configured to advertise the LB address, rather than the actual address of the service. This is also where the URL re-writing would occur to identify the individual node. An example of a class that creates the endpoint metadata is "RegistrationCoordinatorInitialisation". I don't know what support popular load balancers have for the type of URL re-writing that I mention here. This should be investigated. was: Enabling session affinity on the load balancer should ensure that all requests for a particular application endpoint, within a particular session, go to the same instance of the web service. However, XTS advertises a number of endpoint addresses that will not make sense in a load balanced cluster. This is because it would be the internal endpoint address of the particular server that is advertised, rather than the load balancer's external address. Even if we configured XTS (not yet possible) to offer the address of the LB, we would still have a problem as XTS will use a different session to the application to send protocol messages and thus they will go to a different server that is not aware of this transaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira