Hi Shazni and Pirinthapan,
thanks for the clarification.
On Tue, Dec 2, 2014 at 1:28 PM, Shazni Nazeer sha...@wso2.com 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 '
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
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.
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
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.
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]
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
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
