OSGeo - User contributions [en]

MapGuide RFC 3 - Session Affinity

2006-11-16T19:12:22Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

=Overview=

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

=Motivation=

Configuring a load balancer to distribute requests between multiple MapGuide instances should be simple. The need to ensure that a session-related request is always directed to the server that originally created that session makes configuration of a load balancer undesirably complicated.

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer is typically used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if those resources are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server, when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. The proposal is to modify MapGuide to handle this problem so that the load balancer can direct incoming requests to any of its available web tier deployments. This allows the load balancer configuration to be trivial.

=Funding/Resources=

Autodesk to supply the resources to make the required changes.

=Proposed Changes=

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

The proposed solution is to use the following approach:

i) Allow the "IPAddress" and "Port" settings in webconfig.ini to be specified as comma-separated lists, thus allowing a 1:n relationship between the web tier and site server(s) instead of the current 1:1 relationship.

ii) Create a singleton object that persists for the lifetime of the web tier that is capable of distributing requests from the web tier to each of the available site servers using a round-robin algorithm.

iii) Include the IP address of the site server in the ID of any session that it hosts. The IP address would be encrypted and would form a part of the session ID string.

iv) Modify the MgCommand object (which creates the connection from the web tier to the site server) to detect requests that are dependent upon a session. For such requests, the site server IP address will be extracted and decrypted from the session ID. If that IP address matches one that is configured for this web tier, the connection will be made to that site server. If the IP address does not match any of the web tier's site server IPs, an error message will be returned.

For requests that do not depend upon a session, the singleton class will be used to send the request to the next site server in the round-robin sequence.

v) The Server Admin PHP pages are currently dependent upon the 1:1 relationship between the web tier and site server. The login page would need to be updated to present a dropdown list of available site servers to configure. In the case where the web tier is only configured to access one site server, this field could be hidden or disabled. The login process would create a new session on the selected site server, and all subsequent interactions from the pages would be locked to that site via the session ID.

=Implications=

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

=Test Plan=

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-16T19:11:14Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

=Overview=

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

=Motivation=

Configuring a load balancer to distribute requests between multiple MapGuide instances should be simple. The need to ensure that a session-related request is always directed to the server that originally created that session makes configuration of a load balancer undesirably complicated.

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer is typically used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if those resources are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server, when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. The proposal is to modify MapGuide to handle this problem so that the load balancer can direct incoming requests to any of its available web tier deployments. This allows the load balancer configuration to be trivial.

=Funding/Resources=

Autodesk to supply the resources to make the required changes.

=Proposed Changes=

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

The proposed solution is to use the following approach:

i) Allow the "IPAddress" and "Port" settings in webconfig.ini to be specified as comma-separated lists, thus allowing a ''1 to n'' relationship between the web tier and site server(s) instead of the current ''1 to 1'' relationahsip.

ii) Create a singleton object that persists for the lifetime of the web tier that is capable of distributing requests from the web tier to each of the available site servers using a round-robin algorithm.

iii) Include the IP address of the site server in the ID of any session that it hosts. The IP address would be encrypted and would form a part of the session ID string.

iv) Modify the MgCommand object (which creates the connection from the web tier to the site server) to detect requests that are dependent upon a session. For such requests, the site server IP address will be extracted and decrypted from the session ID. If that IP address matches one that is configured for this web tier, the connection will be made to that site server. If the IP address does not match any of the web tier's site server IPs, an error message will be returned.

For requests that do not depend upon a session, the singleton class will be used to send the request to the next site server in the round-robin sequence.

v) The Server Admin PHP pages are currently dependent upon the 1:1 relationship between the web tier and site server. The login page would need to be updated to present a dropdown list of available site servers to configure. In the case where the web tier is only configured to access one site server, this field could be hidden or disabled. The login process would create a new session on the selected site server, and all subsequent interactions from the pages would be locked to that site via the session ID.

=Implications=

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

=Test Plan=

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 4 - KML Support

2006-11-07T18:28:08Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

*Submission Date:
*Last Modified Date:
*Author: Chris Claydon
*RFC Status: (draft, proposed/pending vote, adopted or rejected)
*Implementation Status: under development
*Voting History:
*Assigned PSC guide(s):

=Overview=

Google Earth allows external data to be overlaid upon its own vast collection of satellite imagery and vector graphics. It does this by supporting KML - an XML-based format that can be used to define how external vector and raster data may be dynamically loaded and displayed within the Google Earth application.

=Motivation=

By integrating MapGuide with Google Earth, we provide a compelling way for users to visualize their data in relation to the planet as a whole. In addition to satellite imagery, Google provides a large amount of useful content, such as road networks, points of interest, voting districts etc. By serving up MapGuide data via KML (and its compressed form, KMZ) we allow users to incorporate their specific data set with Google's.

So, for example, if a MapGuide data set contained information about underground pipes and sewers, this information could be overlaid on a satellite image showing individual streets and houses. This would greatly facilitate the process of estimating exactly which homes and streets would be affected by any maintenance required on those pipes.

=Funding/Resources=

Resources supplied by Autodesk.

=Proposed Changes=

A new service will be added to MapGuide that supports three request types - GetMapKml, GetLayerKml and GetFeaturesKml.

'''GetMapKml''' is designed to be the single point of user-initiated contact with the server. It takes the following parameters:

OPERATION = GetMapKml

VERSION = 1

MAPDEFINITION = <map definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

This request can be made from a URL link in a web page. It generates a KML document representing the requested map definition. This document contains one NetworkLink element for each layer in the map. Google Earth uses these elements to make GetLayerKml requests back to MapGuide to retrieve further dynamic data for each layer.

If the format is KMZ, the KML document is compressed inside a zip file before being returned in the response. The mime types returned for KML and KMZ responses cause Google Earth to start up automatically and display the content of the document. If the requested format is XML, the mime type returned is text/xml, and the text of the KML document is typically displayed directly in the browser window.

'''GetLayerKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetLayerKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

The KML generated by the GetMapKml request populates the first 5 of these parameters, and the link is formatted in such a way that Google Earth provides the BBOX, WIDTH and HEIGHT parameters corresponding to its current view.

GetLayerKml returns a KML document containing a <NetworkLink> element corresponding to each scale range supported by the layer that is currently visible. <Region> elements are used to instruct Google Earth only to request data via these links when the current scale falls within the scale range and when the current map extent intersects the extent of the data.

'''GetFeaturesKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetFeaturesKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

GetFeaturesKml returns the actual content to be rendered on the map. For feature layers, a KML document is returned that contains the features represented in vector format, plus style information such as the color, line width etc. For raster layers, the raster image is returned in PNG format. Drawing layers (from DWF files) will not be supported (yet).

=Implications=

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

=Test Plan=

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

MapGuide RFC 4 - KML Support

2006-11-06T18:43:05Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

*Submission Date:
*Last Modified Date:
*Author: Chris Claydon
*RFC Status: (draft, proposed/pending vote, adopted or rejected)
*Implementation Status: under development
*Voting History:
*Assigned PSC guide(s):

=Overview=

Google Earth allows external data to be overlaid upon its own vast collection of satellite imagery and vector graphics. It does this by supporting KML - an XML-based format that can be used to define how external vector and raster data may be dynamically loaded and displayed within the Google Earth application.

=Motivation=

By integrating MapGuide with Google Earth, we provide a compelling way for users to visualize their data in relation to the planet as a whole. In addition to satellite imagery, Google provides a large amount of useful content, such as road networks, points of interest, voting districts etc. By serving up MapGuide data via KML (and its compressed form, KMZ) we allow users to incorporate their specific data set with Google's.

So, for example, if a MapGuide data set contained information about underground pipes and sewers, this information could be overlaid on a satellite image showing individual streets and houses. This would greatly facilitate the process of estimating exactly which homes and streets would be affected by any maintenance required on those pipes.

=Funding/Resources=

Resources supplied by Autodesk.

=Proposed Changes=

A new service will be added to MapGuide that supports three request types - GetMapKml, GetLayerKml and GetFeaturesKml.

'''GetMapKml''' is designed to be the single point of user-initiated contact with the server. It takes the following parameters:

OPERATION = GetMapKml

VERSION = 1

MAPDEFINITION = <map definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

This request can be made from a URL link in a web page. It generates a KML document representing the requested map definition. This document contains one NetworkLink element for each layer in the map. Google Earth uses these elements to make GetLayerKml requests back to MapGuide to retrieve further dynamic data for each layer.

If the format is KMZ, the KML document is compressed inside a zip file before being returned in the response. The mime types returned for KML and KMZ responses cause Google Earth to start up automatically and display the content of the document. If the requested format is XML, the mime type returned is text/xml, and the text of the KML document is typically displayed directly in the browser window.

'''GetLayerKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetLayerKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

The KML generated by the GetMapKml request populates the first 5 of these parameters, and the link is formatted in such a way that Google Earth provides the BBOX, WIDTH and HEIGHT parameters corresponding to its current view.

GetLayerKml returns a KML document containing a <NetworkLink> element corresponding to each scale range supported by the layer that is currently visible. <Region> elements are used to instruct Google Earth only to request data via these links when the current scale falls within the scale range and when the current map extent intersects the extent of the data.

'''GetFeaturesKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

=Implications=

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

=Test Plan=

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

MapGuide RFC 4 - KML Support

2006-11-06T18:31:08Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

*Submission Date:
*Last Modified Date:
*Author: Chris Claydon
*RFC Status: (draft, proposed/pending vote, adopted or rejected)
*Implementation Status: under development
*Voting History:
*Assigned PSC guide(s):

=Overview=

Google Earth allows external data to be overlaid upon its own vast collection of satellite imagery and vector graphics. It does this by supporting KML - an XML-based format that can be used to define how external vector and raster data may be dynamically loaded and displayed within the Google Earth application.

=Motivation=

By integrating MapGuide with Google Earth, we provide a compelling way for users to visualize their data in relation to the planet as a whole. In addition to satellite imagery, Google provides a large amount of useful content, such as road networks, points of interest, voting districts etc. By serving up MapGuide data via KML (and its compressed form, KMZ) we allow users to incorporate their specific data set with Google's.

So, for example, if a MapGuide data set contained information about underground pipes and sewers, this information could be overlaid on a satellite image showing individual streets and houses. This would greatly facilitate the process of estimating exactly which homes and streets would be affected by any maintenance required on those pipes.

=Funding/Resources=

Resources supplied by Autodesk.

=Proposed Changes=

A new service will be added to MapGuide that supports three request types - GetMapKml, GetLayerKml and GetFeaturesKml.

'''GetMapKml''' is designed to be the single point of user-initiated contact with the server. It takes the following parameters:

OPERATION = GetMapKml

VERSION = 1

MAPDEFINITION = <map definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

This request can be made from a URL link in a web page. It generates a KML document representing the requested map definition. This document contains one NetworkLink element for each layer in the map. Google Earth uses these elements to make GetLayerKml requests back to MapGuide to retrieve further dynamic data for each layer.

If the format is KMZ, the KML document is compressed inside a zip file before being returned in the response. The mime types returned for KML and KMZ responses cause Google Earth to start up automatically and display the content of the document. If the requested format is XML, the mime type returned is text/xml, and the text of the KML document is typically displayed directly in the browser window.

'''GetLayerKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetLayerKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

The KML generated by the GetMapKml request populates the first 5 of these parameters, and the link is formatted in such a way that Google Earth provides the BBOX, WIDTH and HEIGHT parameters corresponding to its current view.

'''GetFeaturesKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

=Implications=

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

=Test Plan=

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

MapGuide RFC 4 - KML Support

2006-11-06T18:28:37Z

Wiki-Chrisclaydon:

This page contains an change request (RFC) for MapGuide Open Source.
More MapGuide RFCs can be found on the [[MapGuide RFCs]] page.

=Status=

*Submission Date:
*Last Modified Date:
*Author: Chris Claydon
*RFC Status: (draft, proposed/pending vote, adopted or rejected)
*Implementation Status: under development
*Voting History:
*Assigned PSC guide(s):

=Overview=

Google Earth allows external data to be overlaid upon its own vast collection of satellite imagery and vector graphics. It does this by supporting KML - an XML-based format that can be used to define how external vector and raster data may be dynamically loaded and displayed within the Google Earth application.

=Motivation=

By integrating MapGuide with Google Earth, we provide a compelling way for users to visualize their data in relation to the planet as a whole. In addition to satellite imagery, Google provides a large amount of useful content, such as road networks, points of interest, voting districts etc. By serving up MapGuide data via KML (and its compressed form, KMZ) we allow users to incorporate their specific data set with Google's.

So, for example, if a MapGuide data set contained information about underground pipes and sewers, this information could be overlaid on a satellite image showing individual streets and houses. This would greatly facilitate the process of estimating exactly which homes and streets would be affected by any maintenance required on those pipes.

=Funding/Resources=

Resources supplied by Autodesk.

=Proposed Changes=

A new service will be added to MapGuide that supports three request types - GetMapKml, GetLayerKml and GetFeaturesKml.

'''GetMapKml''' is designed to be the single point of user-initiated contact with the server. It takes the following parameters:

OPERATION=GetMapKml

VERSION=1

MAPDEFINITION=<map definition stored in repository>

DPI=<the resolution of the display used by the caller> (defaults to 96)

FORMAT=KML, KMZ or XML

This request can be made from a URL link in a web page. It generates a KML document representing the requested map definition. This document contains one NetworkLink element for each layer in the map. Google Earth uses these elements to make GetLayerKml requests back to MapGuide to retrieve further dynamic data for each layer.

If the format is KMZ, the KML document is compressed inside a zip file before being returned in the response. The mime types returned for KML and KMZ responses cause Google Earth to start up automatically and display the content of the document. If the requested format is XML, the mime type returned is text/xml, and the text of the KML document is typically displayed directly in the browser window.

'''GetLayerKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

OPERATION = GetLayerKml

VERSION = 1

LAYERDEFINITION = <layer definition stored in repository>

DPI = <the resolution of the display used by the caller> (defaults to 96)

FORMAT = KML, KMZ or XML

BBOX = <minx,miny,maxx,mayy> the current map extent in WGS84 lat/lon coordinates

WIDTH = the current map width in pixels

HEIGHT = the current map height in pixels

The KML generated by the GetMapKml request populates the first 5 of these parameters, and the link is formatted in such a way that Google Earth provides the BBOX, WIDTH and HEIGHT parameters corresponding to its current view.

'''GetFeaturesKml''' is designed to be called only by Google Earth. Its format may change in order to accomodate future enhancements to our KML support. It is therefore not recommended to call this operation directly. It supports the following parameters:

=Implications=

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

=Test Plan=

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

MapGuide RFC 4 - KML Support

2006-11-03T21:04:11Z

Wiki-Chrisclaydon:

MapGuide RFC 4 - KML Support

2006-11-03T20:52:51Z

Wiki-Chrisclaydon:

MapGuide RFC 4 - KML Support

2006-11-03T18:04:17Z

Wiki-Chrisclaydon:

MapGuide RFC 4 - KML Support

2006-11-03T17:58:28Z

Wiki-Chrisclaydon:

MapGuide RFC 3 - Session Affinity

2006-11-01T22:46:05Z

Wiki-Chrisclaydon:

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

=Overview=

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

=Motivation=

Configuring a load balancer to distribute requests between multiple MapGuide instances should be simple. The need to ensure that a session-related request is always directed to the server that originally created that session makes configuration of a load balancer undesirably complicated.

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer is typically used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if those resources are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server, when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. The proposal is to modify MapGuide to handle this problem so that the load balancer can direct incoming requests to any of its available web tier deployments. This allows the load balancer configuration to be trivial.

=Funding/Resources=

Autodesk to supply the resources to make the required changes.

=Proposed Changes=

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

=Implications=

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

=Test Plan=

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T22:39:29Z

Wiki-Chrisclaydon:

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

=Overview=

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

=Motivation=

Configuring a load balancer to distribute requests between multiple MapGuide instances should be simple. The need to ensure that a session-related request is always directed to the server that originally created that session makes configuration of a load balancer undesirably complicated.

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer is typically used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. The proposal is to modify MapGuide to handle this problem so that the load balancer can direct incoming requests to any of its available web tier deployments. This allows the load balancer configuration to be trivial.

=Funding/Resources=

Autodesk to supply the resources to make the required changes.

=Proposed Changes=

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

=Implications=

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

=Test Plan=

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T22:27:29Z

Wiki-Chrisclaydon:

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

=Overview=

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

=Motivation=

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer will typically be used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. Configuring a load balancer to determine the session and direct the request to a particular web tier instance would be complex and undesirable.

The proposal is to modify MapGuide to handle the problem so that the load balancer configuration can be trivial.

=Funding/Resources=

Autodesk to supply the resources to make the required changes.

=Proposed Changes=

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

=Implications=

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

=Test Plan=

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T22:24:40Z

Wiki-Chrisclaydon:

=Status=

This section should include the following:

*Submission Date: November 1, 2006
*Last Modified Date: November 1, 2006
*Author: Chris Claydon
*RFC Status: draft
*Implementation Status: pending
*Voting History:
*Assigned PSC guide(s):

===Overview===

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

===Motivation===

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer will typically be used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. Configuring a load balancer to determine the session and direct the request to a particular web tier instance would be complex and undesirable.

The proposal is to modify MapGuide to handle the problem so that the load balancer configuration can be trivial.

===Funding/Resources===

Autodesk to supply the resources to make the required changes.

===Proposed Changes===

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

===Implications===

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

===Test Plan===

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T21:33:53Z

Wiki-Chrisclaydon:

===Overview===

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

===Motivation===

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer will typically be used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. Configuring a load balancer to determine the session and direct the request to a particular web tier instance would be complex and undesirable.

The proposal is to modify MapGuide to handle the problem so that the load balancer configuration can be trivial.

===Funding/Resources===

Autodesk to supply the resources to make the required changes.

===Proposed Changes===

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

===Implications===

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

===Test Plan===

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T21:33:06Z

Wiki-Chrisclaydon:

===Overview===

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

===Motivation===

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer will typically be used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. Configuring a load balancer to determine the session and direct the request to a particular web tier instance would be complex and undesirable.

The proposal is to modify MapGuide to handle the problem so that the load balancer configuration can be trivial.

===Funding/Resources===

Autodesk to supply the resources to make the required changes.

===Proposed Changes===

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of accessing sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

===Implications===

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

===Test Plan===

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 3 - Session Affinity

2006-11-01T21:25:58Z

Wiki-Chrisclaydon:

===Overview===

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

===Motivation===

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer will typically be used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if they are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server(s) knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. Configuring a load balancer to determine the session and direct the request to a particular web tier instance would be complex and undesirable.

The proposal is to modify MapGuide to handle the problem so that the load balancer configuration can be trivial.

===Funding/Resources===

Autodesk to supply the resources to make the required changes.

===Proposed Changes===

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of accessing sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.
2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.
3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

====Technical====

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

===Implications===

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

===Test Plan===

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.

MapGuide RFC 4 - KML Support

2006-10-31T18:44:48Z

Wiki-Chrisclaydon:

===Overview===

This section brefly describes the problem set, and the proposed solution in general terms. It should be deliberately short, a couple of sentences or so.

===Motivation===

This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be.

===Funding/Resources===

This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could potentially do so if they are sure they have the funding to cover the change.

===Proposed Changes===

This is a more detailed description of the actual changes desired. The contents of this section are tailored to the type of RFC - web site changes are different from technical changes for instance. We need to develop guidelines on what the standard types of proposals are, and what sub-sections could be included here for each type.

====Technical====

This section could include details on files affected, schema changes, potential API changes etc.

===Implications===

This is wide open.

===Test Plan===

How the proposed change will be tested, if applicable

MapGuide RFC 3 - Session Affinity

2006-10-31T18:43:22Z

Wiki-Chrisclaydon: