You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Isuru Haththotuwa <is...@wso2.com> on 2013/12/31 14:51:53 UTC
[Proposal] Persisting Subscription Information in Registry
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.
[image: Inline image 1]
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* <http://wso2.com/>*
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Isuru Haththotuwa <is...@wso2.com>.
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 <im...@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 <la...@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 <is...@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 <is...@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/>*
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Imesh Gunaratne <im...@apache.org>.
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 <pr...@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 <im...@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 <la...@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 <is...@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 <is...@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/
>
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Pradeep Fernando <pr...@gmail.com>.
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 <im...@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 <la...@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 <is...@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 <is...@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/
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Imesh Gunaratne <im...@apache.org>.
+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 <la...@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 <is...@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 <is...@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
>
>
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Isuru Perera <is...@wso2.com>.
On Sun, Jan 5, 2014 at 8:26 AM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> +1 since this will avoid the burden of managing a DB / scripts for that.
>
So, this means there will be no tables to maintain subscriptions,
cartridges etc information?
AFAIU, this mail thread just says that by using the Registry, the
subscription can be accessed as Resource.
I don't see any disadvantage of having the subscription details in a
properly defined tables in the database. Caching can be used in this
scenario as well.
It would be great to see detailed comparisons of existing design and the
proposed design.
Thanks!
> 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 <is...@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 <is...@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
>
>
--
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
about.me/chrishantha
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Lahiru Sandaruwan <la...@wso2.com>.
+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 <is...@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 <is...@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
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Isuru Haththotuwa <is...@wso2.com>.
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 <is...@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/>*
Re: [Proposal] Persisting Subscription Information in Registry
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
Hi Isuru,
Is this a distributed cache model?
On Tue, Dec 31, 2013 at 7:21 PM, Isuru Haththotuwa <is...@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
>
>