stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: [Proposal] Persisting Subscription Information in Registry
Date Sun, 05 Jan 2014 14:20:25 GMT
+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
>
>

Mime
View raw message