On Mon, Jul 15, 2013 at 9:36 AM, Sagara Gunathunga <[email protected]> wrote:
> > > > On Mon, Jul 15, 2013 at 8:15 AM, Samisa Abeysinghe <[email protected]>wrote: > >> So, version means: >> 1. version number appears in URL in addition to the name >> 2. version number appears in war file name in addition to the name >> >> That is all? >> > > From AS core that's all. Handling default version, changing default > version time to time and mapping incoming messages to current default > version ( e.g - mapping "/app" to " /app/CurrentDefaultVersion" ) need to > be done in a layer in front of AS, as we realized to do those logic with AS > we need to fork and modify Tomcat code drastically but even we do so we > have to face number of performance issues as Tomcat architecture directly > deal with Java Socket and low level byte processing on incoming streams. > So that best approach is to have URL-Rewrite component in ELB level. > Yes. AS does not need to worry about routing the traffic. It only needs to host multiple versions of a webapp and serves requests coming to them (need to provide distinct URLs for them). This should be handled at ELB level. > > Thanks ! > > >> >> >> On Fri, Jul 12, 2013 at 1:01 PM, Sagara Gunathunga <[email protected]>wrote: >> >>> >>> >>> >>> On Fri, Jul 12, 2013 at 12:20 PM, Supun Malinga <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> +1 for option 1 (using the tomcat's default support). That's straight >>>> forward and simple than the other options. >>>> >>>> However we should test it thoroughly to see if we have tomcat's exact >>>> behavior.. >>>> >>> >>> I did few testing on this, in fact we can reuse schema and some internal >>> processing from Tomcat but still we have to do some improvements as I >>> suggested in option-1. The reason is we don't use Tomcat deployers instead >>> Carbon deployers so we need some logic to handle versioning within Web >>> Application deployers otherwise application deploy with "/myapp#20" context >>> path instead of "/myapp/20". With suggested naming schema changes above >>> Option-1 can be modified as follows. >>> >>> >>> 1. Say user upload a webapp called "mvcapp.war" with version number "2.0" >>> 2. Assume above web app will be copied to "webapps" directory of AS as >>> "mvcapp#20.war" >>> 3. During the deployment it detect file name contains "#" pattern and >>> call to handle versioning >>> 4. Finally deployer deploy above mvcapp#20.war app with "/mvcapp/20" >>> context path. >>> >>> 5. Now above app can be accessed using following URL >>> >>> http://192.168.1.4:9763/mvcapp/20 <http://192.168.1.4:9763/mvcapp/v20> >>> >>> >>> Note - According to the doc when it come dispatching to a version Tomcat >>> use following algorithm. >>> >>> If no session information is present in the request, use the latest >>> version. >>> If session information is present in the request, check the session >>> manager of each version for a matching session and if one is found, use >>> that version. >>> If session information is present in the request but no matching >>> session can be found, use the latest version. >>> >>> >>> But in our case we don't need always dispatch to the latest version >>> instead users need a control to define the default version and change it >>> time to time also other versions of same application should be uniquely >>> accessible too hence I don't think above algorithm can be used in our >>> case so still we need URL -ReWriting component in front of AS. >>> >>> Thanks ! >>> >>> >>>> thanks, >>>> >>>> >>>> On Fri, Jul 12, 2013 at 11:56 AM, Sagara Gunathunga <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jul 12, 2013 at 6:06 AM, Kishanthan Thangarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Sagara, >>>>>> >>>>>> >>>>>> On Thu, Jul 11, 2013 at 2:43 AM, Sagara Gunathunga >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> I'm working on ${Subject} to come up with an architectural design to >>>>>>> cater aPaaS requirements. At the moment I came up with following ideas >>>>>>> it's better if we can start a discussion here to find best option among >>>>>>> them or new best approach. >>>>>>> >>>>>>> (a) Option 1 - Use context-postfix ( like we use context-prefix to >>>>>>> handle webapps belong to tenants) >>>>>>> ======================== >>>>>>> >>>>>>> 1. Say user upload a webapp called "mvcapp.war" with version number >>>>>>> "2.0" >>>>>>> >>>>>>> 2. Assume above web app will be copied to "webapps" directory of AS >>>>>>> as "mvcapp__v20.war" ( For the moment let's forget how we create >>>>>>> mvcapp__v20.war file, we have full control on this area) >>>>>>> >>>>>>> 3. During the deployment it detect file name contains "__v" pattern >>>>>>> and call to handle versioning >>>>>>> >>>>>>> 4. Finally deployer deploy above mvcapp__v20.war app with >>>>>>> "/mvcapp/v20" context path. >>>>>>> >>>>>>> 5. Now above app can be accessed using following URL >>>>>>> >>>>>>> http://192.168.1.4:9763/mvcapp/v20 >>>>>>> >>>>>> >>>>>> >>>>>> For option-1 above, instead of bringing our own way of app >>>>>> versioning, can't we use the same approach that tomcat follows [1] ? >>>>>> >>>>>> The following table is copied from the tomcat doc page for reference. >>>>>> >>>>>> Context Path Context VersionContext Name Base File NameExample File >>>>>> Names (.xml, .war & directory) /foo*None* /foofoo foo.xml, foo.war, >>>>>> foo/foo/bar *None*/foo/bar foo#barfoo#bar.xml, foo#bar.war, foo#bar >>>>>> *Empty >>>>>> String**None* *Empty String*ROOT ROOT.xml, ROOT.war, ROOT/foo 42 >>>>>> /foo##42 foo##42foo##42.xml, foo##42.war, foo##42 /foo/bar42 >>>>>> /foo/bar##42foo#bar##42 foo#bar##42.xml, foo#bar##42.war, foo#bar##42 >>>>>> *Empty String*42 ##42ROOT##42 ROOT##42.xml, ROOT##42.war, ROOT##42 >>>>>> So here is how the versioning works in tomcat. >>>>>> >>>>>> The context name, context path and base file name are closely >>>>>> related. "##" is used to add the version and "#" is used to add another >>>>>> context to the path. >>>>>> >>>>>> As a given example above, foo##42.war will have /foo as the context >>>>>> path and 42 as the version. In here, if there are one or more version of >>>>>> the same app, the latest version takes precedence and the requests gets >>>>>> dispatched to that. >>>>>> >>>>>> "#" can be added to have hierarchical context value for the app. >>>>>> >>>>> >>>>> It seems I discover the same thing but in reverse order :) if we >>>>> have above support that's more than enough to handle our use cases in fact >>>>> I used "__v" instead of "#". >>>>> >>>>> >>>>>> >>>>>> So why don't we follow the same approach as above? >>>>>> >>>>>> Also I have some questions related to $subject. >>>>>> 1. Do we need to have all the version of a particular app deployed at >>>>>> all time? >>>>>> >>>>> >>>>> It's up to the user, if user want to run all of them we should >>>>> facilitate. >>>>> >>>>> >>>>>> 2. Is there a requirement to distinguish the version of a app in the >>>>>> URL like http://192.168.1.4:9763/mvcapp/v20 ? >>>>>> >>>>> >>>>> It's just how i came up with my initial design but we can go according >>>>> to above table. >>>>> >>>>> Thanks ! >>>>> >>>>>> >>>>>> Thanks, >>>>>> Kishanthan. >>>>>> [1] >>>>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming >>>>>> >>>>>>> >>>>>>> Special Notes >>>>>>> -------------------- >>>>>>> >>>>>>> 1. Unlike tenant use cases in above option .WAR file get unpacked >>>>>>> during the deployment but due to suggested modification .WAR file name >>>>>>> and >>>>>>> unpacked directory name are not identical. >>>>>>> >>>>>>> e.g - .WAR file - "mvcapp__v20.war" >>>>>>> Unpacked directory - "mvcapp#v20" ( We don't have >>>>>>> any control to change this behavior) >>>>>>> >>>>>>> Due to this fact during the undeployment unpacked directory will >>>>>>> remains without deleting, but this is not an issue as we can detect the >>>>>>> pattern and can delete unpacked directory through the undeployment. >>>>>>> >>>>>>> >>>>>>> 2. After deployment app's Context URL will remains constant we can't >>>>>>> dynamically change it. Here it's not possible to change default >>>>>>> version of >>>>>>> the app just using Tomcat or AS through Admin UI. >>>>>>> >>>>>>> e.g - >>>>>>> http://192.168.1.4:9763/mvcapp/v10 >>>>>>> http://192.168.1.4:9763/mvcapp/v10 >>>>>>> http://192.168.1.4:9763/mvcapp/v30 >>>>>>> >>>>>>> In order to change default version time to time we need to have >>>>>>> URL-Rewriting component ( within ELB ? ) in front of AS. URL-Rewriting >>>>>>> component should handle followings. >>>>>>> >>>>>>> * It can receive messages (cluster messages ?) from AS when the >>>>>>> default version of app get changed. >>>>>>> >>>>>>> * Based on current default version it should able to redirect >>>>>>> incoming messages to correct app version on AS. >>>>>>> >>>>>>> * If it's a required feature, it should hide actual context URL on >>>>>>> AS from users and have to always requite URL like mod_rewrite do . >>>>>>> >>>>>>> >>>>>>> >>>>>>> (b) Option 2 - Add Proxy or adapter to existing ProtocolHandlers >>>>>>> ======================== >>>>>>> >>>>>>> This idea is to wrap or create proxies for existing Tomcat >>>>>>> ProtocolHandlers so that we can intercept messages before send to actual >>>>>>> ProtocolHandlers but this seems not straightforwards thing without >>>>>>> losing >>>>>>> major performance level. When receiving a message Tomcat directly deal >>>>>>> with Java Socket and and when finding a URL of a message it act on byte >>>>>>> level processing hence it hard to intercept in this area while keeping >>>>>>> same >>>>>>> level of performance. Tomcat use a class called "Mapper" to dispatch >>>>>>> incoming messages to correct Context but we don't have any point to >>>>>>> intercept until this mapping happened. AFAIK Valves get hit after >>>>>>> context >>>>>>> matching happened so we can't use them here. >>>>>>> >>>>>>> One alternative is to write and maintenance our own set of >>>>>>> ProtocolHandlers but this is not straightforward as it sounds and really >>>>>>> complex task to keep same performance level. >>>>>>> >>>>>>> >>>>>>> >>>>>>> (c) Option 3 - Customize Tomcat's Mapper Class >>>>>>> =================================== >>>>>>> >>>>>>> Complexity wise this is not hard and we can cater all our aPaaS >>>>>>> requirements in once place but the cost is we have to fork Tomcat >>>>>>> locally >>>>>>> and maintain, upgrading according to Apache released versions is the >>>>>>> biggest challenge in long run and generally not a good idea. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Among above 3 options personally I prefer options-1 as it less >>>>>>> complex and less effect to current Tomcat and AS architectures and I >>>>>>> already having working prototype. Also any way the prosed URL- >>>>>>> Rewrite component is useful to ELB. >>>>>>> >>>>>>> >>>>>>> Comments ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks ! >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sagara Gunathunga >>>>>>> >>>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kishanthan Thangarajah* >>>>>> Senior Software Engineer, >>>>>> Platform Technologies Team, >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - +94773426635 >>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sagara Gunathunga >>>>> >>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>> Blog ; http://ssagara.blogspot.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Supun Malinga, >>>> >>>> Senior Software Engineer, >>>> WSO2 Inc. >>>> http://wso2.com >>>> http://wso2.org >>>> email - [email protected] <[email protected]> >>>> mobile - 071 56 91 321 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sagara Gunathunga >>> >>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>> V.P Apache Web Services; http://ws.apache.org/ >>> Linkedin; http://www.linkedin.com/in/ssagara >>> Blog ; http://ssagara.blogspot.com >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
