stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pradeep Fernando <pradee...@gmail.com>
Subject Re: [Proposal] Persisting Subscription Information in Registry
Date Mon, 06 Jan 2014 03:56:59 GMT
Hi Imesh,

Thats why we thought of following RXT/property model. The data will be
decoupled from the application.

--Pradeep


On Sun, Jan 5, 2014 at 7:50 PM, Imesh Gunaratne <imesh@apache.org> wrote:

> +1 A great thought Isuru. One question:
> In your proposal are you planning to store the data model as serialized
> objects in the Registry?
>
> If so will it be possible to change the data model at some point and
> upgrade an existing Stratos Manager instance to the latest without loosing
> data?
>
> Thanks
>
>
> On Sun, Jan 5, 2014 at 8:26 AM, Lahiru Sandaruwan <lahirus@wso2.com>wrote:
>
>> +1 since this will avoid the burden of managing a DB / scripts for that.
>>
>> We may add distributed caching to our road map. May be using Hazelcast
>> after we finished the migration to Carbon 4.2.0...
>>
>> Thanks.
>>
>>
>> On Sat, Jan 4, 2014 at 8:12 PM, Isuru Haththotuwa <isuruh@wso2.com>wrote:
>>
>>> Hi Kishanthan,
>>>
>>> Currently this is not a distributed cache. Stratos Manager, in which we
>>> store this information is not clustered at the moment. We will have to
>>> consider the distributed model once Stratos Manager is clustered.
>>>
>>>
>>>
>>> On Sat, Jan 4, 2014 at 11:46 AM, Kishanthan Thangarajah <
>>> kshanth2101@gmail.com> wrote:
>>>
>>>> Hi Isuru,
>>>>
>>>> Is this a distributed cache model?
>>>>
>>>>
>>>>
>>>> On Tue, Dec 31, 2013 at 7:21 PM, Isuru Haththotuwa <isuruh@wso2.com>
>>>> wrote:
>>>> >
>>>> > Hi Devs,
>>>> >
>>>> > To persist Subscription information given by a user at the time of
>>>> cartridge a subscription, we can use a Registry. Subscription information
>>>> are not dynamic, they do not regularly change. However, these data might
be
>>>> required at runtime for various operations. By using a registry, we can
>>>> store the subscription details as a Resource, and access it when required.
>>>> >
>>>> > However, one pitfall this approach can have is accessing registry
>>>> being relatively expensive. So, if we access the Registry frequently in
>>>> runtime, it would lead to a performance degradation. Therefore, I thought
>>>> to use an in-memory cache so that we don't have to access the registry each
>>>> and every time we need to access some information. The idea is to populate
>>>> the cache when required, and in runtime avoid accessing the registry, and
>>>> use the cached data.
>>>> >
>>>> > I have included a very high level diagram of the proposed solution.
>>>> Please share your feedback.
>>>> >
>>>> >
>>>> > The scenarios would be:
>>>> >
>>>> > 1. We populate the cache when required (startup time / tenant loading
>>>> time), with any existing Subscription details
>>>> > 2. Subsequent retrievals are catered to with the cached information
>>>> > 3 & 4. Any changes (very infrequent) or new Subscriptions would
be
>>>> updated in the cache first, and then the Registry. Ideally, updating the
>>>> registry should be a non-blocking call.
>>>> >
>>>> > --
>>>> > Thanks and Regards,
>>>> >
>>>> > Isuru H.
>>>> > Software Engineer, WSO2 Inc.
>>>> > +94 716 358 048
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> Software Engineer, WSO2 Inc.
>>> +94 716 358 048* <http://wso2.com/>*
>>>
>>>
>>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Software Engineer,
>> Platform Technologies,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> email: lahirus@wso2.com cell: (+94) 773 325 954
>> blog: http://lahiruwrites.blogspot.com/
>> twitter: http://twitter.com/lahirus
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>


-- 
Pradeep Fernando.
http://pradeepfernando.blogspot.com/

Mime
View raw message