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 Mon, 06 Jan 2014 08:00:27 GMT
Hi IsuruH/Pradeep,

Great! A name value pair/property model would work in that sense.

Thanks
Imesh


On Mon, Jan 6, 2014 at 9:26 AM, Pradeep Fernando <pradeepfn@gmail.com>wrote:

> 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