Measuring/Billing database usage in StratosLive - Summery

This Article collects all the posts under the Measuring/Billing database usage in StratosLive.

My Job
WSO2 Data Services Server User Guide
Need to find I/O rates, bandwidth used by each Database user
Limiting The Resource Use
I continued
Suggestions and replies
Collecting and summarizing the captured data
Followed the BAM samples.
Do you need data to play with?
Prototype version 1
Prototype version 1 has to be verified.
1st Verification
OSGi Services
Publishing to BAM
Using OSGi console to debug things

[Break for Test Automation]

Back to the Frozen project
WSO2 Storage Server
The Inevitable Change
Strange things do happen
Using Hive Scripts to Analyze and Summarize BAM data
Difference between two time ignoring the date
Replacing for ntask(quartz-scheduler), using timer task
It is almost 'THE END'

It is almost 'THE END'

Now this is the summery of What I have done

 It is agreed to measure the database space usage by each tenant. Here we will not limit the tenant(in terms of database access) on its DB usage but will keep track on excess DB space use by each tenant.

Component level view of the process.

Changes to each component:

Rss-manager: This component will be used to gather usage data from the RSS. And this will add those data to a queue which in turn will be retrieved by usage agent component. This Usage data collection will be handle through couple of newly added classes. And this is scheduled to be run daily. And it is configurable to run starting from a given time and repeated with given time gap(currently decided to run it in 24h intervals). Here we will only interested in tenants with exceeded usage. So it is needed to know the usage plan of a interested tenant, in order to get its limits. We thought of only publishing information about those tenants who exceeds the space limits, due to two reasons.

1. To reduce the data transfer between components and to the BAM server.
2. Exceeded DB size is all we need for billing calculations.

Usage-agent: This component will retrieve usage data from the queue(above mentioned) in the rss-manager. This is handled by newly added class, DatabaseUsageDataRetrievalTask. This is also scheduled to be run daily. And it is configurable to run starting from a given time and repeated with given time gap(currently decided to run it in 24h intervals).

Stratos-commons: This is where usage plan details are manipulated. Here plan details are read from 'multitenancy-packages.xml' and made available for use through a service. Here I have changed the xml file, xml reading class, data storing bean, to contain DB usage related data.

Dependencies: this depends on the yet to develop component (to get the tenant usage plan given the tenant domain/id) and that component is required for the RSS-Manager component changed to work perfectly.

OSGi Services

Full system(carbon core + products) is built as a combination of OSGi bundles. Some of theses bundles expose services at OSGi level. I have to use them to get the tenant usage plan.

There is a service in manager which gives the usage plan of the tenant. To use it first I have to catch them, unluckily those manager component that is needed for the service it not there in the DSS, so we have to add them to DSS temporary as a feature. core and mgt are placed in DSS as a feature. First we thought is putting those to into droppings. But it didn't work as mgt package tried to start before core which is not possible as it requires core. Because of that we have to make it as a feature.

After putting them we have catch that service. Those are normally catches at serviceComponents(one class with 'activate' method). Below is how I did it. There are some methods that is used to bind and unbind the service objects we have to have them where we catch the service

I added the osgi comments as below  

/** 
 * @scr.component name="org.wso2.carbon.rssmanager" immediate="true" 
 * @scr.reference name="default.tenant.billing.service" 
 *                interface="org.wso2.carbon.stratos.common.TenantBillingService" 
 *                cardinality="1..1" policy="dynamic" 
 *                bind="setTenantBillingService" 
 *                unbind="unsetTenantBillingService" 
 * @scr.reference name="user.realmservice.default" 
 *                  interface="org.wso2.carbon.user.core.service.RealmService" 
 *                  cardinality="1..1" policy="dynamic" 
 *                  bind="setRealmService" 
 *                  unbind="unsetRealmService" 
 */ 

then I added following methods

/** 
     * osgi bind method for RealmService 
     * @param tenantBillingService 
     */ 
    protected void setRealmService(RealmService realmService) { 
        this.realmService = realmService; 
    } 

    /** 
     * osgi unbind method for RealmService 
     * @param tenantBillingService 
     */ 
    protected void unsetRealmService(RealmService realmService) { 
        this.realmService =null; 
    } 
   
    /** 
     * returns a RealmService objects that is used to get the tenant list. 
     * @param tenantBillingService 
     */ 
    private RealmService getRealmService() { 
        return realmService; 
    }

After catching it I can use it as below,

if(realmService!=null){ 
        TenantManager tenantManager = getRealmService().getTenantManager(); 
        Tenant[] tenants; 
        try { 
            tenants = (Tenant[]) tenantManager.getAllTenants(); 
            for (int i = 0; i < tenants.length; i++) { 
               // check for each tenant 
            } 
        } catch (UserStoreException e1) { 
            // TODO Auto-generated catch block 
            e1.printStackTrace(); 
        } 
        }else{ 
            System.out.println("realmService NULL"); 
        }

Problems came across Service was not available in DSS First I tried to catch this in my own java class (not in RSSManagerServiceComponent) which was OK but was not the standard. Standard is to catch it in RSSManagerServiceComponent. Anyway it should work, on matter how we do it. In my case it didn't work for tenant.billing.service . Problem was same service (tenant.billing.service not realmservice) was caught in RSSManagerServiceComponent before coming in to my class. This is where I figured out the importance of that standard. Had to include lot of other jar files in droppings.