stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Haththotuwa <isu...@wso2.com>
Subject Re: [Proposal] Persisting Subscription Information in Registry
Date Sun, 05 Jan 2014 14:33:48 GMT
If we store them as serialized data in binary form, it won't be possible to
change the data model without losing existing data. The initial
implementation would be using this approach, but the plan is to eventually
use property/value pairs to build the information model so that we can
cater to requirements such as the one you have mentioned.


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
>>
>>
>


-- 
Thanks and Regards,

Isuru H.
Software Engineer, WSO2 Inc.
+94 716 358 048* <http://wso2.com/>*

Mime
View raw message