On Wed, Jun 25, 2014 at 12:03 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > > On Wed, Jun 25, 2014 at 9:40 AM, Selvaratnam Uthaiyashankar < > [email protected]> wrote: > >> >> >> >> On Tue, Jun 24, 2014 at 4:21 PM, Sameera Jayasoma <[email protected]> >> wrote: >> >>> We have another alternative to fix this problem. If you implement a >>> handler at the transport phase then you have to perform checks for each and >>> every request which would not be an elegant solution. >>> >> Yes i also thought same. AFAIU it will not add considerable delay as we > have in memory map to check tenant status. When i do load tests for > activated and deactivated tenants didn't noticed considerable performance > drop due to this change. Also noticed that there are similar checks in > other dispatchers as well. > >> >>> How about checking this during the tenant loading time. We simply do not >>> load the tenant if its deactivated. The same logic you've planned to >>> implement in the handler, you can put it in the tenant loading code. >>> >> AFAIU when it comes to tenant loading point, request passed into server > and we have done most of expensive stuff. If we take deactivated tenant > scenario all requests will come up to tenant loading point and fail(and it > will happen again and again). Please share your though on this. We can move > this logic to tenant loading code if its more effective than this. > Lets take 10 tenants in a given system, but only 1 tenant is deactivated. If we put a handler in the transport phase, then we are basically intercepting all the service calls of tenants whereas if we put this logic the tenant loading section, then we are only intercepting requests to the deactivated tenant. Latter solution make sense IMO. Thanks, Sameera. > Thanks, > sanjeewa. > >> >> >> What will happen if the tenant is deactivated after getting loaded? >> >> >> >> >>> >>> Thanks, >>> Sameera. >>> >>> >>> >>> >>> On Tue, Jun 24, 2014 at 2:34 PM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> Here is a brief update on implementation of blocking deactivated tenant >>>> requests. >>>> >>>> *Problem:* >>>> Even if we deactivated tenant, still they can access services(APIs, >>>> proxy etc) deployed in server. This will effect to multitenanted products. >>>> >>>> *Suggested solution:* >>>> Implement dispatcher and engage it in transport phase. So this >>>> dispatcher will check tenants state for each call. Then allow to pass >>>> requests coming from active tenants. If request come to service deployed in >>>> deactivated tenants space then server will return 403 error with message >>>> saying "You are trying to invoke deactivated tenant service" >>>> >>>> For this i implemented dispatcher in org.wso2.carbon.tenant.dispatcher >>>> component(stratos component). It will bundled with stratos common feature. >>>> So this dispatcher will be there in most of products as stratos common is >>>> a basic feature (available in all products). Here we will be maintaining >>>> map to keep tenant id and active/deactivated status(otherwise there would >>>> be performance drawback). This map will be cleared in 15 minutes time >>>> interval. Also we need to engage this dispatcher by adding configuration to >>>> transport phase configurations of axis2.xml file. And we can add this >>>> configuration to axis2.xml and keep it commented as we do not need to >>>> engage it for default scenario. Any suggestions? >>>> >>>> Thanks, >>>> sanjeewa. >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sameera Jayasoma, >>> Software Architect, >>> >>> WSO2, Inc. (http://wso2.com) >>> email: [email protected] >>> blog: http://sameera.adahas.org >>> twitter: https://twitter.com/sameerajayasoma >>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>> Mobile: 0094776364456 >>> >>> Lean . Enterprise . Middleware >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> S.Uthaiyashankar >> VP Engineering >> WSO2 Inc. >> http://wso2.com/ - "lean . enterprise . middleware" >> >> Phone: +94 714897591 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
