stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Imesh Gunaratne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (STRATOS-659) Improve Domain Mappings Functionality to Re-Write URLs in Load Balancer
Date Thu, 29 May 2014 18:01:11 GMT

     [ https://issues.apache.org/jira/browse/STRATOS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Imesh Gunaratne updated STRATOS-659:
------------------------------------

    Description: 
In current Domain Mappings implementation Stratos allows to add domain mappings to service
subscriptions with following parameters: cartridgeType, subscriptionAlias, list of <domainName,
appContext>. 

Stratos Manager sends this information to load balancers via the message broker. Load balancer
keeps domainName in a hash map against its cluster, once a request is received, the cluster
is fetched and request is delegated to the next available member in that cluster without touching
the request path. In the member a Tomcat virtual host could be created with the appContext
to map the incoming request path to actual application path.

However this design might not work with different types of services which may not be able
to use Tomcat virtual hosts. More importantly URL mapping functionality needed to be implemented
in each and every service.

Therefore we could overcome this problem by introducing a new functionality in load balancer
to map URLs and directly delegate the incoming requests to the member applications.

Incoming request: 
https://foo.org/some/file/path?someQueryParam=value

Application Path: 
/tenant/foo.org/app-name/version

LB re-writes it to: 
https://member-ip:port/tenant/foo.org/app-name/version/some/file/path/?someQueryParam=value

  was:
In current Domain Mappings implementation Stratos allows to add domain mappings to service
subscriptions with following parameters: cartridgeType, subscriptionAlias, list of <domainName,
appContext>. 

Stratos Manager sends this information to load balancers via the message broker. Load balancer
keeps domainName in a hash map against its cluster, once a request is received, the cluster
is fetched and request is delegated to the next available member in that cluster without touching
the request path. In the member a Tomcat virtual host could be created with the appContext
to map the incoming request path to actual application path.

However this design might not work with different types of services which may not be able
to use Tomcat virtual hosts. More importantly URL mapping functionality needed to be implemented
in each and every service.

Therefore we could overcome this problem by introducing a new functionality in load balancer
to map URLs and directly delegate the incoming requests to the member applications.

Incoming request: https://foo.org/some/file/path?someQueryParam=value
Application Path: /tenant/foo.org/app-name/version
LB re-writes it to: https://member-ip:port/tenant/foo.org/app-name/version/some/file/path/?someQueryParam=value


> Improve Domain Mappings Functionality to Re-Write URLs in Load Balancer
> -----------------------------------------------------------------------
>
>                 Key: STRATOS-659
>                 URL: https://issues.apache.org/jira/browse/STRATOS-659
>             Project: Stratos
>          Issue Type: Improvement
>          Components: Load Balancer
>            Reporter: Imesh Gunaratne
>            Assignee: Imesh Gunaratne
>             Fix For: 4.1.0
>
>
> In current Domain Mappings implementation Stratos allows to add domain mappings to service
subscriptions with following parameters: cartridgeType, subscriptionAlias, list of <domainName,
appContext>. 
> Stratos Manager sends this information to load balancers via the message broker. Load
balancer keeps domainName in a hash map against its cluster, once a request is received, the
cluster is fetched and request is delegated to the next available member in that cluster without
touching the request path. In the member a Tomcat virtual host could be created with the appContext
to map the incoming request path to actual application path.
> However this design might not work with different types of services which may not be
able to use Tomcat virtual hosts. More importantly URL mapping functionality needed to be
implemented in each and every service.
> Therefore we could overcome this problem by introducing a new functionality in load balancer
to map URLs and directly delegate the incoming requests to the member applications.
> Incoming request: 
> https://foo.org/some/file/path?someQueryParam=value
> Application Path: 
> /tenant/foo.org/app-name/version
> LB re-writes it to: 
> https://member-ip:port/tenant/foo.org/app-name/version/some/file/path/?someQueryParam=value



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message