Hi,
The scenario is, we have mounted SM's registry to the App Factory registry
to remove the remote call for read the resources. but still the write calls
happens via SM. see the image below.
The problem is, once we do a write call to the SM's registry, App Factory
registry cache won't get up
Hi All,
>From what i understand the AF and SM are in different domains that is why
distributed caching will not be able to handle this scenario right?. global
cluster cache invalidation has been done with the use of a pub sub
mechanism ( discussed in archi under "Global cluster cache invalidation
Hi Pulasthi,
Yes. We do not need global invalidation (although it would solve the
problem), but the request is to sink AF Registry cache with the DB. We are
in the same JVM, and we need a method/way to tell registry remove this
particular path from Registry path cache.
thanks,
dimuthu
On Tue,
Hi Dimuthu,
On Tue, Nov 11, 2014 at 2:05 PM, Dimuthu Leelarathne
wrote:
> Hi Pulasthi,
>
> Yes. We do not need global invalidation (although it would solve the
> problem), but the request is to sink AF Registry cache with the DB. We are
> in the same JVM, and we need a method/way to tell regist
Hi,
On Tue, Nov 11, 2014 at 3:43 PM, Pulasthi Supun wrote:
> Hi Dimuthu,
>
> On Tue, Nov 11, 2014 at 2:05 PM, Dimuthu Leelarathne
> wrote:
>
>> Hi Pulasthi,
>>
>> Yes. We do not need global invalidation (although it would solve the
>> problem), but the request is to sink AF Registry cache wi
Hi Dimuthu,
On Tue, Nov 11, 2014 at 4:17 PM, Dimuthu Leelarathne
wrote:
> Hi,
>
>
>
> On Tue, Nov 11, 2014 at 3:43 PM, Pulasthi Supun wrote:
>
>> Hi Dimuthu,
>>
>> On Tue, Nov 11, 2014 at 2:05 PM, Dimuthu Leelarathne
>> wrote:
>>
>>> Hi Pulasthi,
>>>
>>> Yes. We do not need global invalidat
Hi Pulasthi,
So when we are doing global invalidation, what is the method we are going
to use to invalidate the cache within the JVM? :) Or are you going to do it
by magic?
thanks,
dimuthu
On Wed, Nov 12, 2014 at 1:36 PM, Pulasthi Supun wrote:
> Hi Dimuthu,
>
>
>
> On Tue, Nov 11, 2014 at 4:17
Hi,
Given that we know the registry path of the resource of which cache to be
deleted and have an instance of the registry we can manually delete the
cache with a method like removeCache in the below file. However, it's not a
clean or correct way of manipulating the registry cache.
https://github
Hi,
The global cache invalidation implementation is complete long time ago and
the documentation can be found at [1]. This has been tested in registry and
it's working well. However this is implemented to support from carbon 4.3.0
onwards.
[1]
https://docs.google.com/a/wso2.com/document/d/1yWE-3F
Hi all,
Since we don't have any other ways to overcome this issue, I'm going with
the solution by implementing a method to remove the registry cache as
Shazni mentioned in the link. So before we doing a write call to the SM
registry we will call this method to clear the cache for the particular
pa
Hi Shazni,
I checked the code for removeCache method and found that cacheKey is
calculated as below.
*String connectionId = (dataBaseConfiguration.getUserName() != null?
dataBaseConfiguration.getUserName().split("@")[0]:dataBaseConfiguration.getUserName())
+ "@" + dataBaseConfiguration.getDbUrl()
Hi Manjula,
As my understanding cacheKey is a RegistryCacheKey object, which is
different from the cacheId. So we don't need to read the cacheId.
Thanks.
Mahendran Pirinthapan
Software Engineer | WSO2 Inc.
Mobile +94772378732.
On Tue, Dec 2, 2014 at 12:01 PM, Manjula Rathnayake
wrote:
> Hi
Hi Manjula,
Yes. The cacheId that you specify is not the the '*connectionId*' that we
create in the method. When a resource is added to the cache we take the '
*connectionId*' the way it is implemented to create the cache key.
Therefore while retrieving the cache we should use the same way.
Shazn
Hi Shazni and Pirinthapan,
thanks for the clarification.
On Tue, Dec 2, 2014 at 1:28 PM, Shazni Nazeer wrote:
> Hi Manjula,
>
> Yes. The cacheId that you specify is not the the '*connectionId*' that we
> create in the method. When a resource is added to the cache we take the '
> *connectionId*'
14 matches
Mail list logo